Resumo Digital

J2EE
Uma aplicação típica J2EE:


Camada logica:
o Presentation: the web front end (servlet, JSP, JSF)
o Business logic: webservice, EJB
o Information System: JPA, JDBC
Camada física:
o Application Server
o Database
o Storage
O J2EE é em camadas e é distribuído: suportado em J2SE, arquitectura em camadas, objectivos
diferentes, application server (é o centro e é fornecido em runtime).
Projecto
SVN/GIT
Sistema de controlo de versão ou sistema de controlo de revisão
Repositório de ficheiro, muitas vezes os ficheiros de código fonte de programas de
computador, com acesso monitorizado. Cada mudança no código tem os dados consigo
(repositório do code.ua)

Controlo de versão no J2EE
o Implica definição -> ambiente, regras; implica definir que conteúdos têm de
ser controlados -> código, gestão de scripts de projecto/builders, testes e
configuração
FERRAMENTAS DE GESTÃO DE PROJECT/BUILDERS
Ant -> makefile mais poderoso
Maven -> repositórios de bibliotecas e gestão de dependências;
Queres testas a ligação com logica de negócio?
Ex: Como os dados do negocio são apresentados  Mocks/stubs
Opções técnicas no projecto

Pode ser guardado no SVN e executado no Hudson: Netbeans é integrado com Hudson
e SVN

Context: Que application server? Que database?

Testing: estar aplicação ou framework?

Presentation layer: como testar os pontos de acesso (entrada)( UI e API )?

Bussiness logic:
o os meus serviços estão a trabalhar bem( EJB or webservices)? E eu posso
aceder aos meus serviços?

Data layer:
o o que testar? Transições? Consistência de dados?
Nós não apresentamos:



a solução para realizar o TDD eficientemente
a solução para o deploy do TDD e o ambiente J2EE
uma abordagem para gerir o desenvolvimento completo do software
Nós apresentamos:


conceitos básicos de teste e TDD
alguns avaliação em funcionalidades do TDD

soluções técnicas para suportar a equipa de desenvolvimento da aplicação J2EE que
suporta TDD
TDD – Test Driven Development





escrever testes antes de escrever o código em si
correr todos os testes
Teste falha: desenvolver o código para que passe aos testes
Teste passa: desenvolver e refactor o código
Para cada nova funcionalidade: começar tudo de novo
Testing
O que é testing? É um processo?



É o processo de demonstrar que não há erros presentes
É o processo de estabelecer confiança que o programa faz o que é suposto fazer
É o processo de executar o programa com a intenção de encontrar erros
Verificação: verificação tem a ver com construir o software bem
Validação: validação tem a ver com construir o software certo
Testing não pode provar que o software está conforme a especificação.
Passar a um teste:


O software trabalhou
Deduzir que o teste falou para encontrar bugs
Falhar um teste:

Provar a cima de tudo que o software não vai trabalhar
Unit Testing: Is each module does what it suppose to do?
Integration Testing: Do you get the expected result when the parts are put together?
Validation Testing: Does the program satisfy the requirements?
System testing: Does it work within the overall system?
Recomendações essenciais:







Escrever testes simples e limpos
Os nomes dos métodos de teste devem ser frases
Uma frase simples mantem o método de teste focado
Um nome expressivo de teste ajuda quando o teste falha
Detalhes é com o cliente, o resto é com a equipa
Escreve testes executáveis na linguagem que:
o É a mesma linguagem em que está a ser escrita o programa
Refactor os testes e interfaces assim que vais aprendendo mais coisas
Continuous integration - hudson
Ciclo contínuo:


Integração do trabalho
Testa a aplicação
Permite detecção de erros




Mais rápido quanto possível
A partir do compilador de erros
Configuração das notificações do sistema de gestão
Falhas reportadas
Idealmente a integração é feita automaticamente
 Automação do build e do testing
Prática suportada por:
o
o
o
Melhoras:
código para utilizador é integrado num repositório comum
cada integração é verificada por um build automated (incluindo testes)
detecção erros de integração
o
feedback, detecção de erros, colaboração, integração do sistema
Reduziu:
o
o
o
nº de mudanças paralelas que são necessárias
nº de erros encontrados durante os testes
risco técnico e de gestão
Hudson –
Recebe do Sistema de Controlo de revisão os : Tests, Code, a configuração
O hudson faze ele próprio o: build, tests e reports
E faz com o application server o: deploy
O hudson é um servidor de continuos integration: build, deploys, runs e tests projects
automaticamente
Automated Testing
Automação:



repete testes sempre que o codigo é alterado
retira o tédio de testes extensivos
faz o teste mais extensível possível (?)
Precisamos de:


Test Driver -> automatiza o processo de correr o conjunto de testes
Test stub -> simula parte do programa chamado de unit-under-tests
Refactoring
Nome: uma mudança feita na estrutura interna do software ser mais fácil de entender e mais
barato de modificar sem mudar o seu comportamento observável
Verbo: restruturar o software aplicando series de refactoring sem mudar o seu
comportamento observável
Primeiro, o propósito de refactorar é fazer com o software seja mais fácil de perceber e
modificar. Podes fazer muitas mudanças no software que fazem pequenas ou nenhumas
mudanças no comportamento observável. Apenas as mudanças feitas no software para fazer
com que seja mais fácil de entender são os refactoring, e não são notadas essas mudanças
para o utilizador.
O trabalho é feito removendo bits que não estão no sitio certo, reduzindo a quantidade do
codigo, eliminando duplicados.
Refactoring ajuda a encontrar bugs e a programar mais rápido.
Refactoring:



Decomposição de objectos maiores em mais pequenos
Fazer mudanças pequenas e metódicas
Seguir os design patters
Retestar depois de todas as mudanças


Fazendo rerunnig dos unit tests
Se algo breaks, é mais fácil de ver a causa do erro
Requirements
Smart
Specific -> sem all, never, allways
Measurable -> sem best ou worst
Attainable -> completo
Realistic(Relevant) -> preciso
Time-Bound -> sem fast, soon
Functional vs. Non-Functional
Requisitos funcionais descrevem o que o sistema deve fazer e os requisitos não funcionais são
restrições globais no sistema de software.
Funcionais: capturados em use cases, analisados por escrita de diagrama de sequencias
Não funcionais: chamados de software qualities, e normalmente não podem ser
implementados num modulo único do programa
Design Patterns
(the design view)
Creational (criacional)





Abstract Factory -> cria instancia de familia de classes
Builder -> separa construção da representação
Factory Method –> cria instância de classes derivadas
Prototype -> uma instância completamente inicializada para ser copiada ou clonada
Singleton -> uma classe onde existe uma e só uma instância
Structural







Adapter -> combina interfaces de classes diferentes
Bridge -> separa a interface do objecto da sua implementação
Composite -> uma estrutura árvore de objectos simples e compostos
Decorator -> adiciona responsabilidades aos objectos dinamicamente
Facade -> uma classe unica (single) representa um subsistema inteiro
Flyweight -> uma instância usada para partilha eficiente
Proxy -> um objecto representa outro objecto
Behavior




Chain of responsibility -> maneira de passar um request entre uma cadeia de objectos
Command -> encapsula um pedido de comandos como se fosse um objecto
Interpreter -> uma caneira de incluir elementos da linguagem no programa
Iterator -> aceder sequencialemtne a elementes de uma colecção







Mediator -> define comunicação simples entre classes
Memento -> captura estado interno do objecto
Observer -> uma maneira de notificação mudanças a classes
State -> altera o comportamente do objecto quando o estado muda
Strategy -> encapsula os algoritmos dentro da classe
Template method -> adiar passos do algoritmo para uma subclasse
Visitor -> nova operação dentro da classe sem mudanças
SIMILARS
 Abstract Factory , template method, flyweight, singleton --> diversos
 Builder , state, bridge, observer --> hierarquia de herança
 Factory Method , strategy e visitor --> herança - promove interface para classe base e
enterra implementações alternativas em derivadas
 Prototype , command, iterator, mediator, memento --> nuvem - promove X para
"estado do objecto cheio (?)"
 Adapter , facade e proxy --> há relação entre entidades
 Composite , decorador, chain of responsability, Interpreter --> composição recursiva
Introdução
Aplicação web based
Service Provider: servidor web/application



Coordenação: gerir pedidos, conceitos de sessão
Concorrência: gerir pedidos e acessos a recursos
Ex: base de dados, messaging
Client Provider: um simples client



Coordenação: depende da aplicação, cliente só faz pedidos
Concorrência: a concorrência do cliente não é um problema para o provider
Ex: usa serviço usando API por um endpoint público
A aplicação J2EE
É um conjunto de componentes logicas



Interfaces para aceder a funcionalidades: web, http e IIOP
Serviços que fornecem as funcionalidades e/ou contêm a logica: EJB, web services,
REST
Recursos que podem ser usados: persistence, comunicação
Corre no servidor de aplicação

Em runtime e fornece os meios para os objectivos
Pode ser orquestrada
Actor principal: Glassfish -> application server


É um produto componente-based que reside no meio da arquitectura central do
servidor. Fornece serviços de middleware para segurança e gestão, como o acesso a
dados e persistência.
Ambiente de runtime e recursos fornecidos
Running elements in J2EE
Running in J2EE: EJB e Message EJB
Running in WS: web-services e REST
Codigo
JUnit
(introdução)
Testes -> mudança nos requisitos



O teste anterior estava ok, mas ainda não testamos a mudança do requisito
o assertTrue( search("horses","denver") )
Precisamos de refactorar o teste (modificar ou adicionar)
o assertEquals( search("horses","denver colorado") , search("horses","denver") )
O assertEquals() verifica que as duas operações são iguais, e se não são, o teste falha
Uma razão para dar mais importância a interfaces e não a classes reais é:
-- a interface pode permanecer como estava no início
-- a implementação pode mudar e sem refactorada
JUnit




É uma framework para escrever testes repetíveis. É uma instância da arquitectura
xUnit para unit testing a frameworks
É uma ferramenta do software para suportar unit testing
É para ser usado
Não é para ser entendido em todos os detalhes
JUnit tem tags especiais para identificação que métodos são para executar e quando
– @BeforeClass – oneTimeSetUp
– @Before – setUp
– @Test – testEmptyCollection
– @After – tearDown
– @Before – setUp
– @Test – testOneItemCollection
– @After – tearDown
– @AfterClass – oneTimeTearDown
O conceito básico:




Given …
o O que deve lá estar antes dos testes
o Para assegurar que as condições “given” estão ok
When …
o O código no método de teste para fazer acontecer
Then …
o Asserções para verificar o que lá está
Precisamos de limpar? Depois
Conclusão:
Precisamos de saber o que é o nosso sistema para testá-lo
E não precisamos de implementação para definir testes
É basicamente o TDD em prática
TDD e J2EE
Introdução de alguns conceitos: testing, tdd, mock, refactor
Apresentar algumas frameworks: testing, control version, software metrics
É preciso conhecer algumas técnicas: para as configurações do desenvolvimento da framework
Alguns problemas entre processo e tecnologia: alguns não são exclusivos do TDD e do J2EE
JMOCK
What is a mock?


Testes mock a um objecto fingindo os seus vizinhos
Mock Objects:

o São objectos falsos
o Trabalham como é suposto na interacção
o Trabalham de acordo com as nossas espectativas
Extremamente leves
Ajuda a isolar a componente que está a ser testada dos seus componentes que ela depende.
Criando stubs das componentes e o seu comportamento esperado. Ajuda a desenhar e testar
as relações entre objectos em redor de todo o sistema. Os stubs imitam o comportamente de
objectos reais de maneira controlada.
Tudo por interfaces (everything by interfaces):


Interacção inter-objectos deve ser feita por interfaces
Esta imatação extra pode fazer o código difícil de seguir nos primeiros passos
Injecção de dependência (Dependency Injection):


Os colaboradores do objecto devem saber o que é o objecto
O objecto NÃO deve ter colaboração por si só (itself)
JMOCK
Mockery context = new Mockery();
..new Expectations()
assert(..);
SUMMARY
 “Tell, don’t ask” , como abordagem OO





Objectos desempenham papéis (roles)
São perguntados para desempenhar papéis
Focus na comunicação e interacção
Interfaces
Mudanças no código não mudam logica
 Estado VS interacção baseada em testes
 Mocking e stubs


“test double” para ver se o mock faz o que é esperado
Não há a complexidade dos objectos reais
WebServices
Web Services são aplicações de cliente e servidor que comunicam no WWW por http. WS
fornece um padrao de significados de inter-operação entre aplicações de software correndo
numa variedade de plataformas e frameworks.
SOA – Service Oriented Architecture


Estilo Arquitectura
o Construção de sistemas distribuídos
o Componentes que não estão ligados fortemente
Objectivos
o Remover dependências artificiais para o mínimo
o Ser capaz de reutilizar
Principais conceitos SOA


Serviço
o Fornece um endpoint visível
o Auto contido – so depende deles e de mensagem
o Pode ter policias/contractos – segurança, vocabulário
Mensagem
o Descritiva – deve ter toda a informação necessária
o Idempotente – apenas receber a copia da mensagem, ignora os outros
o Interface simples – codigo
o Extensível
SOA deve ter um mecanismo que permite um consumidor descobrir um prestador de serviço
no contexto do serviço procurado pelo consumidor. O mecanismo pode ser muito flexível e
não tem de ter registro centralizado.
WebServices : web services(1) or Rest(2)
(1)
SOAP, WSDL, UDDI são peças fundamentais da infrastrutura SOA



WSDL - é usado para descrever o serviço
UDDI – para registrar e olhar pelos serviços
SOAP – é a camada de transporte para enviar mensagens entre consumidor e
fornecedor de serviço
Enquanto SOAP é um mecanismo por omissão para web services, há alternativas.
A XML baseado em SOA
o
O consumidor por procurar pelo serviço no registro UDDI, get o WSDL para o
serviço que tem a descrição, e invocar o serviço usando XML baseado em
mensagens (SOAP) em http.
O desenho baseado em SOAP tem de incluir elementos como:
o
WSDL usado para descrever detalhes do contrato das interfaces que o webservice
oferece;
Aqui:
A invocação da operação de web service é representada por um protocolo XML, como SOAP.
A especificação SOAP define a estrutura, as regras, e convenções para representar invocações
e respostas do web servisse. Estas chamas e respostas são transmitidas como mensagens
SOAP (XML files) por http.
(2)
REST – rest é bem adequado para o basico, cenários de integração ad-hoc. Restfull web
services, muitas vezes melhor integrados com http do que com SOAP, não quererem
mensagens XML nem definições de WSDL.
Rest é mais apropriado quando:

O web service é completamente stateless. Um bom teste é considerar se a interecção
pode sobreviver ao restart do servidor.
O ambiente:

Glassfish; broker e endpoint (WSDL); tipicalmente suportado em servlet
A mensagem: codificada em xml/json
A comunicação: por http, protocolo baseado em texto; webservices usa SOAP
http e servlets




renuncia: não há intenções de explicar o http em detalhe
web services recebem pedidos http
Pedidos são:
o GET – pedido “pequeno”
o POST – pedido com “anexos”
o PUT – normalmente não é usado
o DELETE – normalmente não é usado
As servlets ficam com estes pedidos
o No J2EE/netBeans usando Servlets extended Classes
Servlet - a servlet é um programa, que recebe e responde a pedidos do client web
(normalmente através de http, ou seja, estas comunicações são realizadas sobre http)
Servlets -> maven ; add form -> servlet
@WebServlet(name = "CalcServlet(nome)", urlPatterns = {"/CalcServlet"}(path))
public class CalcServlet extends HttpServlet {
..
protected void processRequest(HttpServletRequest request(request), HttpServletResponse
response)
throws ServletException, IOException { (http handler)
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter(); (response)
NOTA: devemos criar primeiro o web.xml (todo suportado por servlets) e depois adicionar a
servlet
(Maven - Servlets)
Sample REST example:
-> path
- " @Path("/orders/") "
-> lifecycle
- " @Interceptors(CallAudit.class) "
-> an EJB
- " @Stateless "
-> using EJB
- " @EJB BillingService billing;
@EJB DeliveryService delivery;
@EJB Warehouse warehouse; "
-> http response
- @PUT
@Produces({"application/xml","application/json"})
@Consumes({"application/xml","application/json"})
@GET
@Path("{orderid}/")
@Produces({"application/xml","application/json"})
-> using JPA
- @PersistenceContext
EntityManager em;
Order found = this.em.find(Order.class, orderId);
O que escolher: ws ou rest?
WS -> para requisitos QoS avançados, que ocorre em computação empresarial.. através dos
protocolos fornece segurança e rentabilidade
RS –> é mais fácil de escrever em aplicações web
Criar um webservice
maven -> new webservice
REST resource is a Facade
- Pode representar dados reais, pode seconder processos e usar interface normalizada
Notas:



Tudo isto pode ser feito sem IDE;
WS e REST são soluções técnicas e não a solução
Precisamos de saber e decidir:
o Quais são as funcionalidades da aplicação (uses cases, requirements)
o Como vamos publica-los (REST, WS)


Quando compilamos: o codigo está sinteticamente correcto
Correr: 1º fazer o pack (war), fazemos o deploy do servidor, pelo cliente invocamos o
WS, web page.. e corre no browser e no servidor
• Webservices and REST
– são codificados como stateless EJB (at least in Glassfish)
– com anotações extra
• EJB are not webservices
– EJB usa IIOP – binary, RMI based interface
– Webservices usa SOAP – text, http-based
– REST usa XML/JSON – text, http-based
• O servidor da aplicação gera as diferentes “facets”
(webservice @Stateless and @WebService)
__
WebService
@WebService(serviceName = "NewWebService") (nome)
@WebMethod(operationName = "hello") (operação)
public String hello( (parametros)
txt) {
return "Hello " + txt + " !";
}
@WebParam(name = "name")
(parametros)
String
REST is not SOA/Web Services
REST: a different approach
• Noun – Recursos, referenciavel
• Verb – Operation; Standard HTTP("define some resources and they will have these
methods".): -- GET,PUT,POST, DELETE; Uniform semantic
• Contents – format – Semantics on the programmer
EJB
Enterprise beans corre no container EJB, com glassfish. O enterprise beans é uma componente
server-side que encapsula a logica de negocio da aplicação e implementa a tecnologia EJB.
Corre no container EJB com application server e fornece serviços de system-level
Session Bean -> client único dentro servidor de aplicação, logo só tem um utilizador. Não é
partilhado e não é persistente (dados não são guardados na BD)
Annotations
@PostConstruct
@PrePassivate
@PostActivate
@Remove
@PreDestroy
Stateless: não mantem o estado com o cliente, só preserva o estado a invocação
Statefull: o estado é retido durante toda a sessão
Singleton Session Beans: é instanciado um por aplicação e existe por todo o ciclo de vida da
aplicação
EJB based webservices:



Aplicação web padrão não é suportada por containers EJB
Usando maven
Opções: ou procurar projecto semelhantes ou enterprise application com IDE
(fazer no netbeans)
Maven - Enterprise Application - New WebService...
• Now replicate the servlet and form
– In the web application
• Create the EJB and WS
– In the EJB module
...web service - web service client - call web service operation
JSF – Java server faces
Camada de apresentação: gateway para o sistema pelo exterior; outside vs inside; ..
A tecnologia JSF fornece um modelo de programação bem definido e bibliotecas. Com isto é
mais fácil construir e manter a aplicação web com interface de utilizador server-side.
Com esforço mínimo podes:






Criar a pagina web;
Drop componentes na pagina adicionando tags
“Bind components on a page to server-side data.”
“Wire component-generated events to server-side application code”
Guardar e restaurar o estado da aplicação
Reusar componentes
Outside ? Web front-end -> Glassfish com internet explorer, mozila, chrome..
JSF:

Java framework para construção de aplicações web

Abordagem component-centric : “drag and drop” UI design; colecção de components;
usa MVC design pattern (model-view-controler): o runtime gera as dependências e os
eventos
O que é a aplicação JSF?




Conjunto de paginas JSP, de backing beans;
Uma configuração de recursos: regras
A deployment descriptor (web.xml)
Objectos comuns como components, validators
Java Server Page (JSP) é um document de texto que contem 2 tipos de texto: dados estáticos e
elementos JSP. A tecnologia jsp é considerado a tecnologia “velha” para jsf.
Dados estáticos – podem ser em html, xml..
Elemento JSP – constroem dinamicamente o contente
Facelets é uma parte de especificação de jsp e também a tecnologia preferida para construção
de aplicações de JSF. É uma pagina poderosa mas leve que é usada para construir as views JSF
usando o estilo html. Ou seja:


Facelets usam xhtml para criar paginas web
Templating para componentes e paginas
Front end: Servlet + JSP





Front end http
Contentes dinâmicos no lado do cliente: scripting
Servlet: lida com o pedido http
JSP: estrutura de componentes IU; Mapeia componentes UI em codigo
Beans gerido: lida com UI e logica de negocio
JPA – Java Persistence API
J2EE define JPA como solução de persistência além da opção fornecida pelo java (que é a JDBC)
JPA fornece a desenvolvedores de java um objecto de mapeamento racional para gestão
racional de dados nas aplicações java
4 areas:




A JP API
A linguagem da query
A java persistence criteria API
Object/relational mapping metadata
Entities
É um objecto leve do domino da persistência. Representa uma tabela na base da dados
relacional, e cada instancia da entidade corresponde a uma coluna da tabela.
O primeiro artefacto é o entity class.
O estado de persistência de uma entidade é representado por campos ou propriedade
persistentes (anotações).
Requisitos para entity classes:






A classe tem de ter anotado a anotação de javax.persistence.Entity
A classe tem de ter um construtor sem argumentos e ser publica ou protegida (e pode
ter outros construtores)
A classe não pode ser declarada com final, bem como metodos os instancias
persistentes
É preciso implementar a interface seriazable se uma instancia da entity é passada por
valor
Entities devem extender classes entity e não entity, e as classes não entity devem
extender a classe entity
As instancias da entity devem ser privadas, protegidas para serem acessidas só pelos
metodos da entity class.
Relações:



One-to-one
o Cada instancia da entidade é relacionada para uma única instancia de outra
entity. (javax.persistence.OneToOne anotação)
One-to-many
o uma instancia da entidade pode ser relacionada com múltiplas instancias de
outras entidades (javax.persistence.OneToMany annotation)
Many-to-one
o

Múltiplas instancias da entity podem relacionar-se com uma única instancia de
outra entity (javax.persistence.ManyToOne annotation)
Many-to-many
o As instancias da entidade podem ser relacionadas com múltiplas instancias de
outras entity (javax.persistence.ManyToMany annotation)
J2EE
A Arquitetura J2EE
Componentes de Aplicação
Aplicações J2EE são compostas de componentes. Para nós, um componente é uma unidade
autocontida de software que pode ser composta numa aplicação em tempo de design (sem
compilação). Componentes J2EE são escritos em Java.
Componentes J2EE na Camada de Apresentação
-Os seguintes componentes podem existir na camada de apresentação:
- "Application client" (cliente não-Web)
-- Tipicamente usa Swing como User Interface (UI)
-- Também chamado "Console Application"
- Applets
Componentes J2EE na Camada Web
Componentes da camada Web podem incluir vários módulos, incluindo:
- Páginas HTML/XML estáticas
- Servlets - Programas em Java que rodam no servidor Web e que processam pedidos
gerando respostas dinâmicas
- Java Server pages (JSP)
-- Templates HTML mais fáceis de criar, mas contendo "scriplets" (trechos em
Java) para a geração de conteúdo dinâmico
-- São convertidas em servlets quando acedidas pela primeira vez
- JavaBeans - Componentes tradicionais em Java que podem ser usados em servlets e
JSPs
Componentes J2EE na Camada de Aplicação
Componentes da camada de aplicação são chamados Enterprise Java Beans (EJB)
-> Há vários tipos de EJBs:
- Session Beans
-- Representam uma conversação transiente com um cliente
-- Quando o cliente termina, a session bean desaparece
- Entity Bean
-- Representam dados persistentes gravados na base de dados (tipicamente
uma linha de uma tabela) -> entity classes
- Message-Driven Bean
-- Uma combinação de um session bean com um Listener de mensagem Java
Message Service (JMS)
-- Permite que um componente de aplicação (o message bean) receba
mensagens assíncronas
-- Isso significa que podemos acoplamento muito fraco entre pedaços da
aplicação: importante quando máquinas remotas estão envolvidas e podem nem estar no ar,
ou pelo menos, poderão não responder de forma síncrona a chamadas remotas
A camada de dados
-> Observe que a camada de chamamos "de dados" pode ser um banco de dados ou outra
coisa:
- Por exemplo, pode ser um sistema ERP, CRM ou outro sistema legado
- Por esse motivo, a camada frequentemente é chamada de "camada EIS"
A ARQUITETURA J2EE
Containers e Serviços
A chave da arquitetura J2EE é que muito trabalho normalmente feito pelo programador é
poupado, já que é feito automaticamente pelo middleware
- O programador se concentra no Business Logic
-> A entidade que faz essa magia é o Container
-> Um container "envolve" um componente de forma a capturar mensagens dirigidas ao
componente e fornecer serviços automáticos a este
-> Portanto, antes de ser usado, um componente (seja cliente, Web ou EJB) deve:
- Ser montado numa aplicação
- Ser "deployed" (implantado) dentro de um container
-> O container pode ser configurado em tempo de deployment
- Com declarative programming, isto é, mudança de atributos
->Exemplos do que se faz no deployment ao configurar um container:
- Estabelecer segurança
- Estabelecer o tratamento transaccional
- Mapear nomes entre a aplicação e os recursos disponíveis
-> O container também gera serviços não configuráveis:
- O lifecycle dos componentes (achar, criar, destruir, ...)
- Pooling de recursos (conexões de bancos de dados, por exemplo)
- Persistência de dados
Tipos de Containers
-> Os seguintes tipos de containers existem e executam no servidor J2EE:
- Container EJB: um tal container para acolher algumas ou todas as Enterprise Beans
(EJBs) de uma aplicação
- Web container: um tal container para acolher algumas ou todas as JSPs e servlets de
uma aplicação
-> Os seguintes tipos de containers existem e executam na máquina cliente:
- Application Client Container: para executar uma aplicação "console"
-> Observe que servlets e JSPs podem executar sem um "J2EE server" completo
- Podem executar num servidor Web com suporte especial sem ter suporte a EJB
- Por exemplo: Apache Tomcat
-> Portanto, na figura abaixo, onde se vê "J2EE server", podemos ter, na realidade, máquinas
diferentes
http://jacques.dsc.ufcg.edu.br/cursos/j2ee/html/intro/j2ee-11.jpg
As APIs do J2EE
-> Java 2 Platform, Standard Edition (J2SE™) - O antigo JDK
-> Enterprise JavaBeans Technology
-> JDBC API Para aceder à base de dados
-> Java Servlet Technology
-> JavaServer Pages (JSP) Technology
-> Java Message Service (JMS) - Para comunicação assíncrona distribuída, fracamente acoplada
e confiável
-> Java Transaction API (JTA) - Para a demarcação de transações
-> JavaMail™ Technology - Para que aplicações possam enviar mail
-> Java API for XML Processing (JAXP) - Para implementar B2B, relatório XML, etc.
-> J2EE Connector Architecture - Para se conectar de forma simples a vários sistemas de
informação corporativos (ERP, BD
-> Java Authentication and Authorization Service (JAAS) - Para prover serviços de autenticação
e autorização