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;

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

Queres testas a ligação com logica de negócio?

Ex: Como os dados do negocio são apresentados Mocks/stubs

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 código para utilizador é integrado num repositório comum

o cada integração é verificada por um build automated (incluindo testes)

o detecção erros de integração

Melhoras:

o feedback, detecção de erros, colaboração, integração do sistema

Reduziu:

o nº de mudanças paralelas que são necessárias

o nº de erros encontrados durante os testes

o 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

Co digo

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

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

Mockery context = new Mockery();

..new Expectations()

assert(..);

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) @WebParam(name = "name") (parametros) String

txt) {

return "Hello " + txt + " !";

}

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