3 - Padrões da Camada de Negócios. Introdução. A camada de negócios encapsula a lógica central da aplicação. Considerações de design incluem
|
|
- Caio Azeredo Caldeira
- 2 Há anos
- Visualizações:
Transcrição
1 Padrões de Projeto J2EE J931 Padrões da Camada de Negócios (EJB) Helder da Rocha argonavis.com.br Introdução A camada de negócios encapsula a lógica central da aplicação. Considerações de design incluem Uso de session beans para modelar ações. Stateless para operações de um único método. Stateful para operações que requerem mais de um método (que retém estado entre chamadas) Uso de session beans como fachadas à camada de negócios Uso de entity beans para modelar dados persistentes como objetos distribuídos Uso de entity beans para implementar lógica de negócio e relacionamentos Eventos e operações assíncronas com message-driven beans Cache de referências para EJBs em Business Delegates , Helder L. S da Rocha 3-1
2 9 Business Delegate Objetivo: isolar cliente de detalhes acerca da camada de negócios. Business delegates funcionam como proxies ou fachadas para cada session bean. Problema Session Bean 1 Cliente Session Bean 2 JNDI Acoplamento forte: cliente contém código de acesso e referências diretas para session beans Session Bean 3 Camada do Cliente ou de Apresentação Camada de Negócios , Helder L. S da Rocha 3-2
3 Descrição do problema Cliente contém referências para detalhes da camada de negócios Nomes JNDI dos componentes Eventuais relacionamentos entre beans Exceções exclusivas de EJBs Acoplamento forte dificulta desenvolvimento da camada de apresentação Cliente fica vulnerável a mudanças no modelo de dados modelado pelos objetos 5 Solução: Business Delegate Business Delegate 1 Session Bean 1 JNDI Cliente Business Delegate 2 Session Bean 2 Business Delegate 3 Session Bean 3 Camada do Cliente ou de Apresentação Camada de Negócios , Helder L. S da Rocha 3-3
4 Descrição da solução Um Business Delegate é uma classe Java comum que encapsula detalhes da camada de negócios e intercepta exceções específicas do EJB isolando-as do cliente Deve-se introduzir um Business Delegate como fachada para cada Session Bean que for diretamente exposto a clientes Business Delegates podem usar um Service Locator para localizar os serviços de negócio (JNDI) 7 Estrutura UML (1) BusinessDelegate: tem o papel de prover controle e proteção para o BusinessService. Pode oferecer dois tipos de construtores Construtor default que utiliza um ServiceLocator para obter uma fábrica para o BusinessService (como um EJBHome) Construtor que recebe um string de ID e o utiliza para obter um Handle para o BusinessService ServiceLocator: encapsula detalhes de localização BusinessService: tipicamente um Session Façade Fonte: [Core] , Helder L. S da Rocha 3-4
5 Diagrama de Seqüência Para evitar futuros lookups no Service Locator e usar o construtor que recebe ID (pode não ser portável entre diferentes servidores) Fonte: [SJC] 9 Melhores estratégias de implementação Delegate Proxy Strategy Interface com mesmos métodos que o Session Façade que está intermediando Pode realizar cache e outros controles Delegate Adapter Strategy Permite integração de um sistema com outro (sistemas podem usar XML como linguagem de integração) , Helder L. S da Rocha 3-5
6 Conseqüências Reduz acoplamento Traduz exceções de serviço de negócio Implementa recuperação de falhas Expõe interface mais simples Pode melhorar a performance com caches Introduz camada adicional Transparência de localidade Oculta o fato dos objetos estarem remotos 11 Exercícios 1. Analise a implementação das estratégias de Business Delegate 2. Refatore a aplicação em ejblayer/bd/ para que utilize Business Delegate: a) Implemente um Business Delegate para fazer interface com entre o Controller Servlet (ou comandos) e o Session Bean principal. b) Trate as exceções e encapsule-as em exceções comuns a todo o sistema , Helder L. S da Rocha 3-6
7 10 Service Locator Objetivo: Isolar dos clientes de serviços de localização de recursos (JNDI) a lógica e informações relacionadas ao serviço oferecendo uma interface neutra. Service locator pode ser usado para abstrair todo uso de JNDI e ocultar as complexidades da criação de objetos. Problema Cliente 1. operaçoes de lookup() em JNDI JNDI Session Bean Entity Bean 2. Construção do canal de comunicação Entity Bean DAO BD MDB 3. Acesso ao recurso Queue Topic , Helder L. S da Rocha 3-7
8 Descrição do problema Clientes de EJBs ou de recursos compartilhados precisam conhecer e usar a API JNDI para obter referências para os recursos desejados Em alguns casos, após a obtenção da referência, é preciso realizar conversões e outras tarefas antes de usar o objeto Criação de objetos, se requerida frequentemente, pode impactar na performance da aplicação, principalmente se clientes e serviços estão localizados em camadas diferentes 15 Solução: Service Locator Cliente 1. Obtenção do canal de comunicação Service Locator lookup() em JNDI JNDI Session Bean Entity Bean 3. Acesso ao recurso Entity Bean DAO BD MDB Queue Topic , Helder L. S da Rocha 3-8
9 Descrição da solução Service Locator centraliza todo o acesso ao servidor JNDI, facilitando Localização de objetos EJBHome (obtenção da referência já convertida para o tipo correto) Localização de serviços como conexões de bancos de dados ou conexões de servidores de messaging Localização de canais e filas JMS Service Locator pode melhorar a performance da pesquisa oferecendo um cache para as pesquisas mais frequentes. 17 Estrutura UML Client: tipicamente é um Business Delegate para localizar beans ou um DAO para localizar bancos de dados ServiceLocator: isola do cliente os detalhes da API de pesquisa Cache: ServiceLocator opcional para guardar referências previamente localizadas Target: serviço ou componente que o cliente busca no ServiceLocator [SJC] , Helder L. S da Rocha 3-9
10 Seqüência [SJC] 19 Melhores estratégias de implementação EJB Service Locator Strategy Usa objeto EJBHome que pode ser armazenado em um cache para evitar uma pesquisa futura JMS Queue Service Locator Strategy e JMS Topic Service Locator Strategy Retornam QueueConnectionFactory e TopicConnectionFactory usados em conexões JMS Retornam filas (queues) e canais (topics) Type Checked Service Locator Strategy Realiza conversões de tipos (ex: narrow()) Web Service Locator Strategy , Helder L. S da Rocha 3-10
11 EJB Service Locator Strategy +getremotehome:ejbhome +getlocalhome:ejblocalhome +getid: String +getejb: EJBObject Target 21 EJB Service Locator Strategy Exercício: inclua o cache neste diagrama! , Helder L. S da Rocha 3-11
12 Conseqüências Abstrai complexidade Oferece acesso uniforme a clientes Facilita adição de novos componentes de negócio Melhora performance de rede Melhora performance de cliente com cache 23 Exercícios 1. Analise a implementação das estratégias de Service Locator 2. Refatore a aplicação em ejblayer/sl/ para que utilize Service Locator: a) Isole todas as chamadas ao JNDI nesta classe b) Altere os componentes (beans e clientes) para que utilizem o Locator para descobrir e obter os recursos desejados , Helder L. S da Rocha 3-12
13 11 Session Façade Objetivo: Simplificar a interface do cliente de enterprise beans e controlar o acesso e a comunicação entre entity beans. Session Façade representa uma função ou várias funções exercidas por um sistema. Problema Lógica de transações Entity Bean 1 Cliente Entity Bean 2 Entity Bean 3 Lógica de negócio Camada do Cliente ou de Apresentação Camada de Negócios , Helder L. S da Rocha 3-13
14 Descrição do problema Cliente precisa de serviços prestados pela camada de negócio A camada de negócios está publicamente exposta através da interface de Entity Beans O cliente precisa descobrir quais beans utilizar, precisa localizá-los (JNDI), tratar eventuais exceções, controlar seus relacionamentos e controlar sua lógica de transações para cada requisição Interface complexa e difícil de usar Fortemente acoplada ao modelo de objetos (vulnerável) 27 Solução: Session Façade Entity Bean 1 Cliente Session Façade Entity Bean 2 Entity Bean 3 Camada do Cliente ou de Apresentação Lógica de transações gerenciada pelo container Camada de Negócios , Helder L. S da Rocha 3-14
15 Descrição da solução Mover a lógica de negócio de interação com Entity Beans para fora do cliente Implementar a fachada do cliente como um Session Bean Reduz-se o número de chamadas remotas do cliente As chamadas estão concentradas na fachada do Session Bean Lógica de transações pode ser implementada no Session Bean ou gerenciada pelo Container (CMT) O cliente não é mais responsável pelo controle de transações Ideal é ter pouca ou nenhuma lógica de negócio Se existir, deve ser colocada em um Application Service 29 Estrutura UML Cliente: tipicamente um Business Delegate SessionFacade: implementada como um session bean. Oculta a complexidade ao lidar com diferentes BusinessComponents BusinessComponent: pode ser um BusinessObject (EJB), DAO ou ApplicationService ApplicationService: encapsula os BusinessObjects e implementa a lógica de negócios para oferecer o serviço DataAccessObject: representa os dados Fonte: [Core] , Helder L. S da Rocha 3-15
16 Diagrama de Seqüência Fonte: [SJC] 31 Melhores estratégias de implementação Stateless Session Façade Strategy Implementada com Stateless Session Bean Ideal se métodos não tem relação alguma entre si (no que se refere a utilização de estado anterior) Stateful Session Façade Strategy Implementada com Stateful Session Bean Necessária se uma operação precisar de mais de uma chamada de método para completar , Helder L. S da Rocha 3-16
17 Conseqüências Introduz camada controladora entre camada de negócios e clientes Expõe interface uniforme Reduz acoplamento Melhora a performance Seleciona apenas métodos de interesse aos clientes Reduz o número de chamadas Centraliza controle de segurança e transações Reduz a interface visível aos clientes 33 Exercícios 1. Analise a implementação das estratégias de Session Façade 2. Refatore a aplicação em ejblayer/sf/ para que utilize Session Façade: a) Crie uma Session Façade que implante toda a funcionalidade do Servlet existente b) Faça o servlet se comunicar com o Façade c) Faça o Façade chamar os métodos utilitários 3. Use um DAO entre o Session Façade e os dados 4. Use um Business Delegate entre o Session Façade e o cliente (Servlet) , Helder L. S da Rocha 3-17
18 12 Application Service Objetivo: Centralizar e agregar comportamento para prover uma camada de serviços uniforme. Application Service serve para oferecer uma camada de serviços que implementa casos de uso para um conjunto de Business Objects Problema Session Bean Entity Bean 1 Session Façade Entity Bean 3 Business Object "POJO" Business Object "POJO" Camada de Negócios DAO , Helder L. S da Rocha 3-18
19 Problema Deseja-se centralizar lógica de negócio atraves de diversos componentes de negócio e serviços Session Façades poderiam fazer isto, mas não devem conter lógica de negócio e devem expor uma interface simples Deseja-se encapsular lógica específica para um usecase fora de Business Objects individuais e independente de Session Façades A coordenação de diversos Business Objects deve ser feita em objetos que possam ser usados por Session Façades e outras fachadas de negócio (nem sempre Business Objects são EJBs) 37 Servlet Solução: Application Service Application Controller Session Façade Application Service Cliente Java Application Service Application Service Entity Bean 1 Entity Bean 3 Business Object "POJO" Business Object "POJO" Camada de Negócios DAO , Helder L. S da Rocha 3-19
20 Solução Application Services oferecem a infraestrutura básica de lógica de negócio usada por Session Façades, As fachadas ficam mais fáceis de implementar e contém menos código Reduzem o acoplamento entre Business Object ao conter a lógica de integração entre eles Permitem ter uma camada central de lógica de negócio mesmo em situações onde não se está usando Business Objects: pode usar um Data Access Object diretamente para acessar dados. Pode oferecer uma interface mais detalhada que um Session Façade e mais genérica que os serviços que isola 39 Por que Application Services? Onde implementar lógica de negócio? Objetos de negócio devem representar os dados, mas devem ter pouca (ou nenhuma) lógica de negócio Application Services são uma camada adicional que pode centralizar a lógica de negócios E Session Façades? Em aplicações EJB, Session Façades tipicamente implementavam a lógica de negócio entre Business Objects Mas a intenção dos Session Façades é oferecer uma interface de baixa granularidade, o que às vezes requer uma sub-fachada com mais detalhes (que pode ser um Application Service) Aplicações que não usam EJB frequentemente precisam de um serviço similar às Session Façades , Helder L. S da Rocha 3-20
21 UML Client: cliente POJO, um Session Façade, outro Application Service ApplicationService: encapsula lógica de negócios para prover um determinado serviço. BusinessObject: objetos necessários para executar o serviço Service: componente arbitrário que oferece um serviço qualquer DataAccessObject: oferece acesso direto aos dados 41 Seqüência , Helder L. S da Rocha 3-21
22 Principais Estratégias Application Service Command Strategy Solução utilizando o Command Pattern (GoF) Cada chamada do cliente, por um Application Controller utiliza uma instância de um objeto de ação, que é executado e que pode chamar métodos de um Application Service Application Service Layer Strategy Os Application Services são distribuídos em cascata Serviços mais genéricos chamam serviços mais específicos Um ApplicationService genérico poderia ser usado por toda a aplicação 43 Conseqüências Centraliza lógica de workflow reutilizável Tira a lógica dos Session Façades Melhora o reuso de lógica de negócio Evita duplicação de código Session Façades e POJO Façades podem compartilhar os mesmos serviços Simplifica implementação de fachadas Introduz camada adicional de negócios , Helder L. S da Rocha 3-22
23 Exercícios 1. Analise os exemplos de código com as estratégias de ApplicationService 2. Refatore a aplicação fornecida para que use Application Service Remova lógica de negócios do Session Façade Remova lógica de comunicação dos Entity Beans Business Object Objetivo: Separar dados de negócio e lógica usando um modelo de objetos. O Business Object é uma abstração que representa uma entidade. Pode ser implementado como um Entity Bean. 2003, Helder L. S da Rocha 3-23
24 Problema Serviço DAO Serviço DAO DAO Camada de Negócios 47 Problema e Motivação Temos um modelo de domínio conceitual que contém lógica de negócio e relacionamento. Objetos compostos que possuem relacionamentos entre si, lógica complexa, regras de validação e negócios Queremos separar o estado e lógica de negócios do comportamento associado ao resto da aplicação Melhorar a coesão Aumentar a chance de reuso Evitar duplicação de código Separar serviços (ações) de estado (entidades) , Helder L. S da Rocha 3-24
25 Definições (USDP) Modelo de negócios Modelo de casos de uso: descreve atores e processos Modelo de objetos: descreve as entidades usadas Modelo de domínio ou modelo conceitual Modelo abstrato que captura os mais importantes tipos de objetos no contexto do sistema Representam as entidades que existem ou eventos que ocorrem no sistema Modelo de objetos Implementação concreta do modelo conceitual Modelo de dados Implementação para banco de dados (ER-model) 49 Solução:Business Object Serviço BO BO DAO DAO BO DAO Serviço BO BO DAO BO DAO BO BO DAO Camada de Negócios , Helder L. S da Rocha 3-25
26 Solução Usar objetos de negócio (Business Objects) para separar dados e lógica de um modelo de objetos Business Objects encapsulam e gerenciam dados, comportamento e persistência de negócios. Ajudam a separar lógica de negócio de lógica de persistência Duas principais estratégias de implementação Usar objetos Java comuns (POJO) e escolher um mecanismo de persistência (DAOs, Domain Store, JDO) Usar entity beans (Composite Entity) e escolher BMP ou CMP como forma de persistência 51 UML Client: tipicamente um Session Façade, objeto Helper (View Helper ou similar) ou um Application Service ParentBO: No modelo de Business Object composto, este é o BO principal que contém BOs dependentes. DependentBO: Objetos independentes gerenciados pelo ParentBO. São fortemente acoplados aos seus pais e deles dependem para gerência do ciclo de vida , Helder L. S da Rocha 3-26
27 Seqüência 53 Estratégias POJO Business Object Strategy Implementação usando objetos Java comuns Requer que programador lide com cache de objetos, pooling, concorrência, sincronização de dados, persistência, segurança, transações Composite Entity Business Object Strategy Implementação usando Entity Beans locais Permite tratamento automático de concorrência, sincronização, pooling, cache e configuração declarativa de transações, segurança, persistência , Helder L. S da Rocha 3-27
28 Conseqüências Promove um enfoque orientado a objetos à implementação do modelo de negócios Distingue-se serviços dos objetos Centraliza comportamento e estado de negócios Cada objeto cuida de sua lógica local. Lógica que age em múltiplos objetos deve ser implementada com Application Service. Separa lógica de persistencia de lógica de negócios Promove arquitetura orientada a serviços 55 Exercícios 1. Analise o código contendo diferentes estratégias de implementação. 2. Refatore a aplicação fornecida Identifique potenciais objetos de negócio Crie os objetos e centralize seu código de lógica de negócios , Helder L. S da Rocha 3-28
29 14 Composite Entity Objetivo: Modelar, representar e gerenciar um conjunto de objetos persistentes relacionados em vez de representá-los como entity beans individuais. Um Composite Entity representa um grafo de objetos. Problema Cliente Entity Bean 1 Interface Remota Container intercepta as chamadas de EJBs Entity Bean 2 (dependente) Contexto da transação , Helder L. S da Rocha 3-29
30 Descrição do problema Relacionamentos entity-to-entity através de interfaces remotas devem ser evitados Difíceis de manter: acoplamento forte Quaisquer chamadas são interceptadas pelo container, trazendo overhead desnecessário (muito overhead se bean acessar o outro via interface remota) Container faz marshalling e unmarshalling de todas as chamadas* Contexto da transação inclui toda a corrente de Entity Beans dependentes, causando problemas de performance e possível deadlock * Container pode otimizar as chamadas, mas isto depende do fabricante 59 Solução: Composite Entity Container intercepta as chamadas de EJBs Chamada local (não interceptada pelo Container) Cliente Entity Bean 1 Objeto dependente (Local EJB ou POJO) Contexto da transação , Helder L. S da Rocha 3-30
31 Descrição da solução Transformar o Entity Bean dependente em um objeto Java comum ou Entity Local Entity beans não devem modelar todos os objetos (fine-grained), apenas os principais Dependências devem ser objetos comuns Chamadas de Entity Beans a seus objetos dependentes não são interceptadas pelo container, resultando em melhor performance Se houver necessidade que outro objeto seja mesmo um Entity Bean, mover a lógica de comunicação para um Session Bean (solução 2) 61 Solução 2: Application Service Chamadas locais Entity Bean 1 Cliente Application Service Entity Bean , Helder L. S da Rocha 3-31
32 Estrutura UML CompositeEntity: entity bean de baixa granularidade que contém objetos dependentes DependentBO: objeto dependente que depende do objeto pai e gerencia seu próprio ciclo de vida. Pode conter outros objetos dependentes Fonte: [Core] 63 Diagrama de Seqüência Fonte: [Core] , Helder L. S da Rocha 3-32
33 Melhores estratégias de implementação Composite Entity é uma das estratégias do padrão Business Object Composite Entity Remote Façade Strategy Nesta estratégia, um Entity Bean remoto é implementado como fachada para os outros beans ou business objects Estratégias para Composite Entity usando BMP Lazy Loading Strategy: a carga de objetos dependentes é realizada apenas no momento do uso Store Optimization Strategy: usa um token para sinalizar se os dados foram alterados para evitar uma atualização desnecessária 65 Conseqüências Elimina relacionamento entre Entity Beans Reduz a quantidade de Entity Beans Melhora a performance da rede Reduz dependência em esquema de BD Aumenta granularidade dos objetos Facilita a criação de TOs compostos , Helder L. S da Rocha 3-33
34 Exercícios 1. Analise a implementação das estratégias de Composite Entity 2. Refatore a aplicação em ejblayer/ce/ para que utilize Composite Entity a) Desenhe o relacionamento atual entre os entity beans. Será que todos os objetos deveriam ser Entity Beans? Justifique sua resposta. b) Utilize a estratégia mais simples para implementar um TO que possa ser enviado pelo cliente, lido, alterado e retornado Transfer Object Objetivo: Reduzir a quantidade de requisições necessárias para recuperar um objeto. Transfer Object permite encapsular em um objeto um subconjunto de dados utilizável pelo cliente e utilizar apenas uma requisição para transferi-lo. 2003, Helder L. S da Rocha 3-34
35 Problema Chamadas Locais Business Delegate Session Façade geta(): A getb(): B getc(): C getd(): D Chamadas Remotas A B Cliente D Chamadas em Entity Beans locais C Camada de Apresentação Camada de Negócios 69 Descrição do problema Cliente precisa obter diversos dados de um Business Object Para obter os dados, é preciso realizar diversas chamadas ao componente As chamadas são potencialmente remotas Fazer múltiplas chamadas através da rede gera tráfego e reduz o desempenho da aplicação , Helder L. S da Rocha 3-35
36 Solução: Transfer Object Chamadas Locais Business Delegate Session Façade getdto: DTO Transfer Object D C A B Chamada Remota Transfer Object D B Cliente Cópia no Cliente Transfer Object construído no servidor com objetos de interesse C A Camada de Apresentação Camada de Negócios 71 Descrição da solução Uma única chamada remota é necessária para transferir o Transfer Object O cliente pode extrair as informações de interesse através de chamadas locais Cópia do cliente pode ficar desatualizada Transfer Object é solução indicada para dados read-only ou informações que não são alteradas com freqüência, ou ainda, quando as alterações não são críticas (não afetam o processo) Objeto alterado pode ser enviado de volta ao servidor , Helder L. S da Rocha 3-36
37 Estrutura UML Client: geralmente um componente de outra camada. Component: qualquer componente de outra camada que o cliente usa para enviar e receber dados. TransferObject: é um POJO (Plain Old Java Object) serializável que contém atributos suficientes para agregar e carregar todos os dados Fonte: [Core] 73 Diagrama de Seqüência Fonte: [Core] , Helder L. S da Rocha 3-37
38 Melhores estratégias de implementação Updatable Transfer Objects Strategy Permite a transferência de um objeto para o cliente, a alteração do objeto pelo cliente e sua devolução ao servidor Multiple Transfer Objects Strategy Permite a criação de Transfer Objects diferentes a partir de uma mesma fonte Entity Inherits Transfer Object Strategy Entity Bean herda de uma classe de Transfer Object Transfer Object Factory Strategy Suporta a criação dinâmica de Transfer Objects 75 Updatable Transfer Object Strategy Fonte: [Core] , Helder L. S da Rocha 3-38
39 Multiple Transfer Object Strategy Fonte: [Core] 77 Entity Inherits Transfer Object Strategy Fonte: [Core] , Helder L. S da Rocha 3-39
40 Conseqüências Simplifica Entity Bean e interface remota Transfere mais dados em menos chamadas Reduz tráfego de rede Reduz duplicação de código Pode introduzir objetos obsoletos Pode aumentar a complexidade do sistema Sincronização Controle de versões para objetos serializados 79 Exercícios 1. Analise a implementação das estratégias de Transfer Object 2. Refatore a aplicação em ejblayer/vo/ para que utilize Transfer Object a) Crie um Transfer Object que representa uma cópia do objeto ProdutoBean b) Implemente no Façade um método que retorne o Transfer Object para o cliente, e outro que o receba de volta a atualize os dados corretamente. b) Refatore o cliente para que ele use esse objeto e extraia os dados corretamente , Helder L. S da Rocha 3-40
41 16 Transfer Object Assembler Objetivo: Construir um modelo ou submodelo de dados requerido pelo cliente. O Transfer Object Assembler usa Transfer Objects para recuperar dados de vários objetos de negócio e outros objetos que definem o modelo ou parte dele. Problema Transfer Object D C A Cliente B Transfer Object D A F G Transfer Object D E E1 E2 Cliente precisa de TOs complexos construídos sob demanda Session Façade Processo de construção do Transfer Object é estático getdto: DTO Transfer Object D C A B E E1 E2 G F Camada de Apresentação Camada de Negócios , Helder L. S da Rocha 3-41
42 Descrição do problema O cliente precisa interagir com múltiplos componentes para obter alguns dados de cada um deles Chamar vários métodos ou vários Transfer Objects menores aumenta o tráfego na rede Cliente se torna fortemente acoplado à interface O servidor precisa saber montar componentes "on-the-fly" de acordo com as necessidades do cliente. 83 Solução: Transfer Object Assembler Transfer Object D C A B Transfer Object D Transfer Object Assembler G A F Transfer Object D E E1 E2 E E1 E2 TransferObject H H1 H2 F D K1 K2 F F K K3 A E E1 E2 M DAO Esses TOs não são um modelo de um componente específico mas da aplicação , Helder L. S da Rocha 3-42
43 Descrição da solução O Transfer Object Assembler constrói um Transfer Object composto (application model) que representa dados de diferentes componentes de negócio Os dados são transportados para o cliente através de uma única chamada Este Transfer Object deve ser imutável, devido à sua complexidade: clientes os utilizam apenas para processamento read-only O servidor obtém transfer objects de vários componentes e utiliza-os para construir um novo Transfer Object composto 85 Estrutura UML Client: objeto interessado em receber dados da aplicação TransferObjectAssembler: constrói um objeto TO composto baseado nos requerimentos da aplicação ApplicationModel: é o TO composto construído pelo TransferObjectAssembler Fonte: [Core] , Helder L. S da Rocha 3-43
44 Diagramas de Seqüência Fonte: [Core] 87 Melhores estratégias de implementação Plain Old Java Object Strategy (POJO) Implementado como um objeto Java comum Servido por um Session Bean Session Bean Strategy Implementado por um Session Bean Stateless Business Object Strategy Pode ser implementado como session bean, entity bean, DAO, objeto Java arbitrário ou outro Transfer Object Assembler , Helder L. S da Rocha 3-44
45 Conseqüências Separa lógica de negócio Reduz acoplamento entre clientes e o modelo da aplicação Melhora performance de rede Melhora performance do cliente Melhora performance das transações Pode introduzir TOs obsoletos Value List Handler Objetivo: Controlar a busca, fazer um cache dos resultados, e oferecer os resultados ao cliente em um cursor (iterator) cujo tamanho e dados adequam-se às requisições do cliente. 2003, Helder L. S da Rocha 3-45
46 Cliente Problema Session Façade Pesquisa com ejbfind() é ineficiente Entity Bean Cliente precisa de dados para exibição Dados vêm de diversos objetos não relacionados Entity Bean find() Entity Bean Entity Bean Item Um Item Dois Item Tres Item Quatro Item Cinco Item Seis Camada de Negócios 91 Descrição do problema Cliente precisa de dados de diversas fontes (diversos objetos diferentes) Dados são somente para leitura Solução: Transfer Object ou TO Assembler Mas, dados não são conhecidos de antemão Cliente quer fazer um query para obter os dados Fazer query com EJBs é ineficiente (métodos finder) ou limitado (EJB-QL) , Helder L. S da Rocha 3-46
47 Solução: Value List Handler Iterator Value List Handler Collection de VOs (cache de resultados) Cliente VO VO VO Faz query diretamente no DAO DAO VO VO VO Item Um Item Dois Item Tres Item Quatro Item Cinco Item Seis Session Façade Entity Bean Entity Bean Camada de Negócios 93 Descrição da solução O Value List Handler acessa o DAO diretamente e faz a sua pesquisa Os dados são armazenados como uma Collection de Value Objects O cliente solicita o ValueListHandler que contém os objetos desejados O Value List Handler implementa o padrão Iterator e permite que o cliente extraia as informações seqüencialmente , Helder L. S da Rocha 3-47
48 Estrutura UML Client: qualquer cliente que precisa executar uma pesquisa que retorne grande quantidade de resultados. ValueListIterator: oferece métodos next(), hasnext(), etc. ValueListHandler: executa a pesquisa e obtém os resultados e os mantém em um objeto ValueList ValueList: Collection que guarda os resultados da pesquisa Value: um objeto de dados resultante da pesquisa Fonte: [Core] 95 Diagrama de Seqüência Fonte: [Core] , Helder L. S da Rocha 3-48
49 Estratégias de implementação Plain Old Java Object (POJO) Handler Strategy Value List Handler implementado como um objeto qualquer pode ser usado por qualquer cliente que precise da facilidade. Útil para aplicações que não usam EJB Business Delegates podem usar um Value List Handler deste tipo para obter uma lista de valores Value List Handler Session Façade Strategy Ideal quando a aplicação usa EJBs na camada de negócio. Bean pode conter estado que implementa o Value List Handler ou pode ser um proxy para um. ValueList from DAO Strategy 97 Conseqüências Alternativa eficiente a EJB finders em pesquisas grandes Faz cache de resultados do lado do servidor Maior flexibilidade de pesquisa Melhora performance da rede Permite separação de interesses em camadas Criação de grandes quantidades de TOs pode ter alto custo , Helder L. S da Rocha 3-49
50 Fontes [SJC] SJC Sun Java Center J2EE Patterns Catalog. J2EEPatternsAtAGlance.html. [Blueprints] J2EE Blueprints patterns Catalog. [Core] Deepak Alur, John Crupi, Dan Malks. Core J2EE Patterns: Best Practices and Design Strategies. Prentice-Hall, Curso J931: J2EE Design Patterns Versão , Helder da Rocha 2003, Helder L. S da Rocha 3-50
Argo Navis J931 - Padrões de Design J2EE. Introdução. Objetivos de aprender padrões J2EE. Conhecer padrões para uso na plataforma J2EE
Padrões de Projeto J2EE J931 Introdução Helder da Rocha (helder@acm.org) argonavis.com.br Objetivos de aprender padrões J2EE Conhecer padrões para uso na plataforma J2EE Padrões permitem maior reuso, menos
4 - Padrões da Camada de Integração. Introdução
Padrões de Projeto J2EE J931 Padrões da Camada de Integração Helder da Rocha (helder@acm.org) argonavis.com.br Introdução A camada de integração encapsula a lógica relacionada com a integração do sistema
Padrões do Catálogo J2EE. Lincoln Souza Rocha, M.Sc. (lincolnrocha@gmail.com)
Padrões do Catálogo J2EE Lincoln Souza Rocha, M.Sc. (lincolnrocha@gmail.com) Livros Deepak Alur, John Crupi e Dan Malks. Core J2EE Patters: Best Practices and Design Strategies, Second Edition (2003).
Argo Navis J931 - Padrões de Design J2EE. Versão 2.0 (setembro de 2003) Objetivos
de Projeto J931 J2EE Versão 2.0 (setembro de 2003) Helder da Rocha (helder@acm.org) argonavis.com.br Objetivos Identificar os principais padrões de projeto J2EE Distinguir os principais padrões de projeto
J550 Padrões de Projeto J2EE para Aplicações Web
J550 Padrões de Projeto J2EE para Aplicações Web Helder da Rocha (helder@acm.org) www.argonavis.com.br 1 Introdução Este módulo aborda os principais padrões de projeto J2EE, dentre o catálogo organizado
Java 2 Enterprise Edition Uma aplicação J2EE completa
Java 2 Enterprise Edition Uma aplicação J2EE completa Helder da Rocha www.argonavis.com.br 1 Objetivos O objetivo deste módulo é construir e implantar uma aplicação J2EE completa Inicialmente, será mostrada
Laboratório EJB e J2EE Uma aplicação completa
J530 - Enterprise JavaBeans Laboratório EJB e J2EE Uma aplicação completa Helder da Rocha (helder@acm.org) argonavis.com.br 1 Objetivos O objetivo deste módulo é construir e implantar uma aplicação J2EE
ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira
ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes
Tecnologias Web. Padrões de Projeto - Camada de Apresentação
Tecnologias Web Padrões de Projeto - Camada de Apresentação Cristiano Lehrer, M.Sc. Padrões da Camada de Apresentação (1/2) Intercepting Filter Viabiliza pré e pós processamento de requisições. Front Controller
Enterprise Java Bean. Enterprise JavaBeans
Enterprise Java Bean Introdução Elementos do Modelo Enterprise JavaBeans A especificação do Enterprise JavaBeansTM (EJB) define uma arquitetura para o desenvolvimento de componentes de software distribuídos
Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Sumário. Java 2 Enterprise Edition. J2EE (Java 2 Enterprise Edition)
Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) J2EE () Sumário Introdução J2EE () APIs J2EE Web Container: Servlets e JSP Padrão XML 2 J2EE é Uma especificação para servidores
Uso de Design Patterns e J2EE: um estudo de caso
Uso de Design Patterns e J2EE: um estudo de caso Rogério Sorroche (FURB) rs@furb.br Maurício Capobianco Lopes (FURB) mclopes@furb.br Resumo. Este trabalho apresenta um estudo de caso sobre o desenvolvimento
Entity Beans. Introdução Entity Beans BMP
Entity Beans Introdução Entity Beans BMP Agenda Conceitos básicos de persistência Definição de entity beans Recursos Conceitos de programação Típos de entity beans Exemplos de entity beans usando Bean-
Histórico de revisões
Design Patterns Histórico de revisões Data Versão Descrição Autor 15/1/2014 1.0 Finalização da primeira versão HEngholmJr OBJETIVOS Fornecer uma visão geral sobre Design Patterns visando atingir os requisitos
Enterprise Java Beans
Enterprise Java Beans Prof. Pasteur Ottoni de Miranda Junior DCC PUC Minas Disponível em www.pasteurjr.blogspot.com 1-O que é um Enterprise Java Bean? O Entertprise Java Bean (EJB) é um componente server-side
Considerações no Projeto de Sistemas Cliente/Servidor
Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis
Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:
MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação
Curso - Padrões de Projeto Módulo 1: Introdução
Curso - Padrões de Projeto Módulo 1: Introdução Vítor E. Silva Souza vitorsouza@gmail.com http://www.javablogs.com.br/page/engenho http://esjug.dev.java.net Sobre o Instrutor Formação: Java: Graduação
UFG - Instituto de Informática
UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 6 EJB Enterprise Java
UTILIZAÇÃO DA TECNOLOGIA ENTERPRISE JAVABEANS NO DESENVOLVIMENTO DE APLICAÇÕES DISTRÍBUIDAS
UTILIZAÇÃO DA TECNOLOGIA ENTERPRISE JAVABEANS NO DESENVOLVIMENTO DE APLICAÇÕES DISTRÍBUIDAS ¹Lucas Martins de Andrade, ¹Jaime William Dias ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil lucasm748@gmail.com
UFG - Instituto de Informática
UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 10 Persistência de Dados
PadrãoIX. Módulo II JAVA. Marcio de Carvalho Victorino. Servlets A,L,F,M
JAVA Marcio de Carvalho Victorino 1 Servlets 2 1 Plataforma WEB Baseada em HTTP (RFC 2068): Protocolo simples de transferência de arquivos Sem estado (não mantém sessão aberta) Funcionamento (simplificado):
1Introdução Helder da Rocha (helder@acm.org)
J930 Padrões Projeto de 1Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas
Testes com Design Patterns
Helder da Rocha (helder.darocha@gmail.com) 31 de março de 2005 71. Que padrão de design pode ser usado para permitir que uma implementação específica e uma hierarquia de abstrações possa variar independentemente?
Programação Orientada a Objetos. Padrões de Criação
Programação Orientada a Objetos Padrões de Criação Cristiano Lehrer, M.Sc. Objetivos Apresentar cada um dos 23 padrões clássicos descrevendo: O problema que solucionam. A solução. Diagramas UML (Unified
Padrões Arquiteturais e de Integração - Parte 1
1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos
PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS.
PADRÕES DE SOFTWARE 1 Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade Grupo de Padrões de Software da UECE (GPS.UECE) Julho-2009 CONTEÚDO Introdução aos Padrões de Software O quê são padrões?
J930. Padrões. Projeto. Introdução. argonavis.com.br. Helder da Rocha (helder@acm.org)
Padrões de J930 Projeto Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas
EJB ainda tem vez no Java EE 6? Fernando Lozano Consultor 4Linux lozano@4linux.com.br
EJB ainda tem vez no Java EE 6? Fernando Lozano Consultor 4Linux lozano@4linux.com.br Você Gosta do EJB? O EJB esteve por muito tempo na berlinda do mundo Java É pesado... É complicado... Código muito
Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos
Programação Avançada Padrões de Projeto de Software 1 Fonte: Oswaldo B. Peres e K19 Treinamentos Introdução Projetar software OO reusável e de boa qualidade é uma tarefa difícil; Para realizar essa tarefa
Padrões Arquiteturais no Java EE 7
Padrões Arquiteturais no Java EE 7 Vagner F. Le Roy Júnior Curso de Pós Graduação em Arquitetura de Software Distribuído Pontifícia Universidade Católica de Minas Gerais Belo Horizonte, MG Brasil vagnerleroy@gmail.com
Introdução à Padrões de Projeto. Glauber Magalhães Pires
Introdução à Padrões de Projeto Glauber Magalhães Pires Agenda O que são padrões de projeto? Para que servem e por que utilizá-los? Elementos constituintes Como escolher o padrão a ser usado? Como são
Como criar um EJB. Criando um projeto EJB com um cliente WEB no Eclipse
Como criar um EJB Criando um projeto EJB com um cliente WEB no Eclipse Gabriel Novais Amorim Abril/2014 Este tutorial apresenta o passo a passo para se criar um projeto EJB no Eclipse com um cliente web
Padrões de Projeto Implementados em Infraestrturas de Componentes
Padrões de Projeto Implementados em Infraestrturas de Componentes Paulo Pires paulopires@nce.ufrj.br http//genesis.nce.ufrj.br/dataware/hp/pires 1 distribuídas baseadas em componentes Comunicação transparente,
Padrão J2EE Data Access Object (DAO)
Introdução CRUD DAO Exemplo Padrão J2EE Data Access Object (DAO) Prof. Enzo Seraphim Motivação para usar Componentes precisam acessar e armazenar informações em armazenamento persistente As APIs de armazenamento
Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br
Padrões GoF Leonardo Gresta Paulino Murta leomurta@ic.uff.br Agenda Introdução Padrões de Criação Padrões de Estrutura Padrões de comportamento Leonardo Murta Padrões GoF 2 Introdução Os padrões GoF (Gamma
1 Criar uma entity a partir de uma web application que usa a Framework JavaServer Faces (JSF)
Sessão Prática II JPA entities e unidades de persistência 1 Criar uma entity a partir de uma web application que usa a Framework JavaServer Faces (JSF) a) Criar um Web Application (JPAsecond) como anteriormente:
Web Technologies. Tópicos da apresentação
Web Technologies Tecnologias de Middleware 2004/2005 Hugo Simões hsimoes@di.fc.ul.pt 1 A Web Tópicos da apresentação Tecnologias Web para suporte a clientes remotos (Applets,CGI,Servlets) Servidores Aplicacionais
UFG - Instituto de Informática
UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação
ARQUITETURA DO SISTEMA ERP PEGASUS
ARQUITETURA DO SISTEMA ERP PEGASUS Elaborado por: Bruno Duarte Nogueira Arquiteto de Software Data: 05/03/2012 1 Sumário 1. Introdução... 3 2. Tecnologias... 3 2.1. Web Tier... 3 2.1.1. Facelets 1.1.14...
Desenvolvendo Aplicações Web com NetBeans
Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo
Padrões de Projeto. Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson
Padrões de Projeto Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson Apresentação Conceitos Definição Ponto de vista prático História Padrões de Projeto Conhecidos
Arquitetura JEE Introdução à Camada de Negócios: Enterprise Java Beans (EJB) Marcos Kalinowski (kalinowski@ic.uff.br)
Arquitetura JEE Introdução à Camada de Negócios: Enterprise Java Beans (EJB) (kalinowski@ic.uff.br) Agenda Arquiteturas Web em Java (Relembrando) Arquitetura Java EE Introdução a Enterprise Java Beans
2 Conceitos relativos a Web services e sua composição
15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados
ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE
ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com
J550. Model View Controller
J550 Model View Controller 1 Design de aplicações JSP Design centrado em páginas Aplicação JSP consiste de seqüência de páginas (com ou sem beans de dados) que contém código ou links para chamar outras
Resumo: Perguntas a fazer ao elaborar um projeto arquitetural
Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Sobre entidades externas ao sistema Quais sistemas externos devem ser acessados? Como serão acessados? Há integração com o legado a ser feita?
UNIDADE IV ENTERPRISE JAVABEANS
UNIDADE IV ENTERPRISE JAVABEANS MODELO J2EE COMPONENTES DE Camada de Negócios NEGÓCIOS JAVA SERVLET, JSP E EJB Nos capítulos anteriores, foi mostrado como desenvolver e distribuir aplicações servlet e
Desenvolvimento Baseado em Componentes e o Processo UML Components
Desenvolvimento Baseado em Componentes e o Processo UML Components Cecília Mary Fischer Rubira Patrick Henrique da Silva Brito Instituto de Computação (IC) Universidade Estadual de Campinas (Unicamp) INF064
Java 2 Enterprise Edition Fundamentos básicos de Transações
Java 2 Enterprise Edition Fundamentos básicos de Transações Helder da Rocha www.argonavis.com.br 1 Objetivos Apresentar conceitos essenciais sobre transações em aplicações J2EE Este curso não aborda o
Mini-curso Gratuito Globalcode Slide 1
Mini-curso Gratuito Slide 1 Mini-curso Gratuito Introdução Enterprise Java Beans (EJB) 3.0 Slide 2 Agenda Plataforma Java EE Conceitos Iniciais (EJB) Session Bean Message-Driven Bean (MDB) Java Persistence
Framework. Marcos Paulo de Souza Brito João Paulo Raittes
Framework Marcos Paulo de Souza Brito João Paulo Raittes Sobre o seu surgimento A primeira versão do spring foi escrita por Rod Johnson em 2002, quando ele estava Lancando o seu livro Expert One-on-One
Sistemas Distribuídos
Sistemas Distribuídos 11 Objetivos Este capítulo apresenta uma introdução aos sistemas distribuídos em geral Arquiteturas de cliente servidor Características das arquiteturas de 2 e 3 camadas Ambiente
Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto
Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto
Desenvolvimento WEB II. Professora: Kelly de Paula Cunha
Desenvolvimento WEB II Professora: Kelly de Paula Cunha O Java EE (Java Enterprise Edition): série de especificações detalhadas, dando uma receita de como deve ser implementado um software que utiliza
PROJETO PEDAGÓGICO DE CURSOS
1 de 6 PROJETO PEDAGÓGICO DE CURSOS BURITREINAMENTOS MANAUS-AM MARÇO / 2015 2 de 6 PACOTES DE TREINAMENTOS BURITECH A Buritech desenvolveu um grupo de pacotes de treinamentos, aqui chamados de BuriPacks,
Projeto de Arquitetura
Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto
Wireshark. Captura de Protocolos da camada de aplicação. Maicon de Vargas Pereira
Wireshark Captura de Protocolos da camada de aplicação Maicon de Vargas Pereira Camada de Aplicação Introdução HTTP (Hypertext Transfer Protocol) 2 Introdução Camada de Aplicação Suporta os protocolos
Prof. Fellipe Araújo Aleixo fellipe.aleixo@ifrn.edu.br
Prof. Fellipe Araújo Aleixo fellipe.aleixo@ifrn.edu.br A arquitetura Enterprise JavaBeans é uma arquitetura de componentes para o desenvolvimento e a implantação de aplicativos de negócio distribuídos
Projeto: Simul-e Documento de Arquitetura de Software
Projeto: Simul-e Documento de Arquitetura de Software Versão 1.0 Página 1 de 9 Histórico da Revisão Data Versão Descrição Autor 12.09.2015 1.0 Criação do Documento Hugo Pazolline 20.10.2015 1.0 Atualização
PROGRAMAÇÃO SERVIDOR PADRÕES MVC E DAO EM SISTEMAS WEB. Prof. Dr. Daniel Caetano 2012-1
PROGRAMAÇÃO SERVIDOR EM SISTEMAS WEB PADRÕES MVC E DAO Prof. Dr. Daniel Caetano 2012-1 Objetivos Compreender o conceito de Padrões de Projeto Compreender o Padrão MVC Conhecer o princípio de alguns dos
Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br
Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Modelos de Dados, Esquemas e Instâncias 2 Modelos de Dados, Esquemas e Instâncias Modelo de dados: Conjunto de conceitos
Padrões clássicos ou padrões GoF O livro "Design Patterns (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, descreve 23 padrões de
Padrões de Projeto Disciplina: Engenharia de Software - 2009.1 Professora: Rossana Maria de Castro Andrade Assistente da disciplina: Ricardo Fernandes de Almeida 1 O que é um Padrão? Um padrão descreve
Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional
Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento
Programação para a Internet. Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala
Programação para a Internet Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala A plataforma WEB Baseada em HTTP (RFC 2068) Protocolo simples de transferência de arquivos Sem estado
Associação Carioca de Ensino Superior Centro Universitário Carioca
Desenvolvimento de Aplicações Web Lista de Exercícios Métodos HTTP 1. No tocante ao protocolo de transferência de hipertexto (HTTP), esse protocolo da categoria "solicitação e resposta" possui três métodos
5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância
5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo
Laboratório de ENGSOF Estudo de Caso. Prof. André Pereira, MSC, PMP
Laboratório de ENGSOF Estudo de Caso Aula de Hoje: Desenvolver um sistema UML inteiro: Aplicação Banco Online. Nosso Estudo de Caso! RSA V7 O que será feito para o projeto? 1) Criando um Projeto UML: 1)
Persistência. 2004 Fernando Lozano, http://www.lozano.eti.br Persistência Objeto-Relacional com Java Pag. 1
Persistência Objeto-Relacional com Java Fernando Lozano http://www.lozano.eti.br Consultor Independente Prof. Faculdades UniABEU Prof. SENAC Editor Adjunto da Revista Java Magazine 2004 Fernando Lozano,
Padrões de projeto 1
Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois
3 SCS: Sistema de Componentes de Software
3 SCS: Sistema de Componentes de Software O mecanismo para acompanhamento das chamadas remotas se baseia em informações coletadas durante a execução da aplicação. Para a coleta dessas informações é necessário
J2EE. J2EE - Surgimento
J2EE Java 2 Enterprise Edition Objetivo: Definir uma plataforma padrão para aplicações distribuídas Simplificar o desenvolvimento de um modelo de aplicações baseadas em componentes J2EE - Surgimento Início:
TDC2012. EJB simples e descomplicado, na prática. Slide 1
TDC2012 EJB simples e descomplicado, na prática Slide 1 Palestrantes Kleber Xavier Arquiteto Senior / Globalcode kleber@globalcode.com.br Vinicius Senger Arquiteto Senior / Globalcode vinicius@globalcode.com.br
Conceitos de Banco de Dados
Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir
Java 2 Enterprise Edition Session Beans
Java 2 Enterprise Edition Session Beans Helder da Rocha www.argonavis.com.br 1 Session Beans São objetos de processo de negócio Implementam lógica de negócio, algoritmos, workflow Representam ações Uma
Java e Banco de Dados: JDBC, Hibernate e JPA
Java e Banco de Dados: JDBC, Hibernate e JPA 1 Objetivos Apresentar de forma progressiva as diversas alternativas de persistência de dados que foram evoluindo na tecnologia Java, desde o JDBC, passando
UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva
UML & Padrões Aula 7 UML & Padrões - Profª Kelly C C Silva Divisão das classes do Modelo de Análise Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades
Aprenda as melhores práticas para construir um completo sistema de teste automatizado
Aprenda as melhores práticas para construir um completo sistema de teste automatizado Renan Azevedo Engenheiro de Produto de Teste e Medição -Américas Aprenda as melhores práticas para construir um completo
Persistência de Dados em Java com JPA e Toplink
Persistência de Dados em Java com JPA e Toplink Vinicius Teixeira Dallacqua Curso de Tecnologia em Sistemas para Internet Instituto Federal de Educação, Ciência e Tecnologia - IFTO AE 310 Sul, Avenida
DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS
DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS Emanuel M. Godoy 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil godoymanel@gmail.com,
Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)
Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,
Engenharia de Software III
Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,
DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES
DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.
Aplicação da Arquitetura Multicamadas Utilizando Java. Raquel Schlickmann Orientador: Marcel Hugo
Aplicação da Arquitetura Multicamadas Utilizando Java Raquel Schlickmann Orientador: Marcel Hugo Roteiro Introdução Histórico da Arquitetura de Software Enterprise JavaBeans - EJB Voyager Implementação
Front-End: corresponde ao que será visualizado pelo utilizador via web. Deve ser acessível para todo e qualquer utilizador.
Projecto Final Introdução O objectivo do projecto final da disciplina de Computação na Internet é colocar em prática todos os conhecimentos adquiridos na disciplina e, assim, desenvolver um sistema que
Laboratório de Programação Web I e Estimativa, Teste e Inspeção de Software
Laboratório de Programação Web I e Estimativa, Teste e Inspeção de Software Apresentação da Disciplina Marcos Camada marcos.camada@catu.ifbaiano.edu.br Objetivo Geral Conhecimento no desenvolvimento aplicações
Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.
Projeto Demoiselle Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.net Palestrantes: Antônio Carlos Tiboni Luciana Campos Mota 20/07/2009
Faculdade Lourenço Filho - ENADE 2011-1
1. Quando se constrói um banco de dados, define-se o modelo de entidade e relacionamento (MER), que é a representação abstrata das estruturas de dados do banco e seus relacionamentos. Cada entidade pode
Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO A4 DATA 23/04/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA
Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info
Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds
Padrões de Projeto WEB e o MVC
Padrões de Projeto WEB e o MVC Padrões de Projeto WEB e o MVC O que são padrões? "Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o cerne da solução para aquele
Service Oriented Architecture (SOA)
São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com
Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064
Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Processos- Clientes, Servidores, Migração Capítulo 3 Agenda Clientes Interfaces de usuário em rede Sistema X Window Software do lado cliente para
3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio
32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de Software Objetivos Contextualizar Análise e Projeto de software dentro de uma metodologia de desenvolvimento (um processo de desenvolvimento de software) Um processo de
UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS
UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,
Java II. Sérgio Luiz Ruivace Cerqueira sergioruivace@gmail.com
Java II Sérgio Luiz Ruivace Cerqueira sergioruivace@gmail.com Por quê JSP? Com Servlets é fácil Ler dados de um formulário Recuperar dados de uma requisição Gerar informação de resposta Fazer gerenciamento
Millennium ECO 2.0 (beta)
MILLENNIUM NETWORK Millennium ECO 2.0 (beta) Documentação Técnica (draft) 10/2013 Este documento contém as instruções para a utilização da biblioteca Millenium_Eco que se presta à comunicação de aplicativos