| Autor |
Mensagem |
|
|
|
qq é isso minha gente!!!
|
 |
|
|
asaudate wrote:
Tecnoage wrote:Discordando de alguns pontos de vista: (Na verdade não acho que sejam pontos de vista, me parece mais informações que faltaram no resumo)
1- Nem sempre o maior benefício de SOA para as empresas é a integração. Na maioria das vezes o maior benefício é a agilidade na composição de distribuição dos serviços. Vide as ferramentas de BPMN que fazem "transformações automáticas" para fluxos BPEL, por exemplo. Tá certo que muito disso é socado goela abaixo pelos tool vendors.
Discordo. Composição de serviços torna as coisas mais lentas (é sempre mais lento usar ferramentas externas para compor serviços do que a própria linguagem em que estes são desenvolvidos. Ou seja, só se usa, mesmo, composição, quando os serviços são desenvolvidos em linguagens diferentes. O que caracteriza integração).
Tecnoage wrote:
2- Outra grande funcionalidade e na minha opinião uma das mais interessantes funcionalidades do ESB, é a pseudo-centralização dos serviços, que proporciona mecanismos para realização de auditorias, controle dos fluxos de mensagens, verificação mais simples e centralizada de gargalos, etc.
E o controle de SLA, e a aplicação de patterns de EAI, e o baixo acoplamento entre serviços... 
Tecnoage wrote:
3- Segundo o que algém indagou sobre performance: Nao falei de performance pensando exatamente em ESBs, falei pensando emn SOA, devido ao overhead de processamento de xmls ( ou outro formato) de memória, e principalmente de I/O de arquivos texto em vez de streams. (embora para tudo isso exista algum paleativo)
Depende da ferramenta utilizada e da capacidade dela. Fazendo uma alusão, JMS também tem overhead entre serialização/desserialização de mensagens. No entanto, uma solução em JMS dá mais agilidade do que se deixar o processamento ser feito de forma assíncrona. No mundo SOA, existem soluções de CEP que só fazem agilizar o processamento. Quanto a I/O de arquivos, acho que você está equivocado. Em SOA, só existe tratamento de arquivos texto como forma de compatibilidade com as antigas práticas de EAI (onde era tudo assim).
Tecnoage wrote:
4- quanto à utilização do BAM, que alguém citou, uma curiosidade: Va verificou a quantidade de memória que o BAM precisa para funcionar??? hehehe
Concordo, às vezes, é uma quantidade absurda. Mas visibilidade compensa o preço de alguns pentes de memória, não? 
[]´s!
Quando à composição dos serviços. CONCORDO, e sua afirmativa não é contrária à minha, é complementar, talvez. Porém sabemos que em termos de qualquer arquitetura, quando reforçamos segurança, por exemplo, geralmente cai performance. É só um exemplo, a mesma coisa acontece com serviços, isso todo mundo sabe, suponho que ja se deva ler isso nas entrelinhas de algumas arquiteturas.
Quanto à parte de performance, onde citei os arquivos texto. Sabemos que isso ocorre, e que deveria funcionar sempre assim, mas vá discutir com qualquer gerente de TI, depois de o pessoal da BEA/WEBLOGIC apresentarem os DBAdapters, TXTAdapters e QUALQUERCOISAADapters, para ver se eles têm a mesma opinião.
Quanto à sua última afirmação, remete um pouco à primeira. Dessa mesma maneira, deve ser "pesado" composição de serviços Vs Overhead. Ou seja, NÃO existe arquitetura de Referência em se tratando de SOA, cada cliente é um cliente, cada projeto, um novo projeto... Pensando assim: " O que seria uns pentes de memória a mais perto de toda flexibilidade que SOA oferece à organização (pelo menos como é vendido pra mesma)...
|
|
|
|
garcia-jj wrote:
Tecnoage wrote:funcionalmente é desse modo que se faz, porém o que procurei ( e ainda procuro ) é algum mecanismo que faça para um relacionamento 1:N lazy, por exemplo a paginação automática, sem a necessidade de criar uma hql ou uma critéria para isso.
Se você ler meu comentário verá que realmente usando o relacionamento não há como fazer paginado. E se você procurar na community manuals do hibernate (não sei se no site do jboss novo tem isso) há um post que fala exatamente do quão ruim é você ter bidirecionais e sair usando algo como:
Sendo que o correto é você ter apenas o relacionamento de Debit.customer, e não ambos Debit.customer e Customer.debits.
A forma mais correta de você paginar é usar o que o Thiago indicou no post dele. Formula mágina para paginação você não irá encontrar.
Não estamos falando necessariamente em relacionamentos bidirecionais, muito pelo contrário.
A meu ver essa paginação AINDA é burra, força meu código "cliente" a fazer iterações baseadas em limites da query. Em termos de código LIMPO, essa é a pior solução, mas até onde encontrei é a única.
Isso geralmente resolve os problemas de sistemas onde ALGUMAS queries podem "explodir" a memória, mas torna sistemas com monstruosas quantidades de informações labirintos lógicos.
E esse é somente uma das limitações do hibernate. Existem uma série de outras, como a não inclusão de tipos PK (simples ou compostas) e qualquer relacionamento em queries do tipo example, por exemplo...
|
|
|
|
|
funcionalmente é desse modo que se faz, porém o que procurei ( e ainda procuro ) é algum mecanismo que faça para um relacionamento 1:N lazy, por exemplo a paginação automática, sem a necessidade de criar uma hql ou uma critéria para isso.
|
|
|
|
ViniGodoy wrote:Eu só esqueci de comentar que eu acho que foi com 9 anos... porque para ser bem sincero, a memória mais antiga que tenho sobre mim, já envolvia eu programando... 
Nerd de nascimento. 
Enfim, minha primeira linguagem foi o basic, do MSX. Comecei copiando os exemplos dos livros.
Depois programei em outras variantes, como o QBasic (alguém aqui também jogava o Gorillaz?).
Fiz meu primeiro curso de programação em 1995, antes do segundo grau. Era um curso de Pascal e Clipper, mas mais focado mesmo em lógica (o curso foi muito bom, por sinal, mesmo que o clipper já estivesse caindo em desuso na época).
Em 1996 entrei no técnico em processamento de dados. E aí sim, comecei a programar para valer. Peguei meu primeiro estágio em 97, ainda com 16 anos. Depois veio a faculdade, o GUJ e a pós...
É, exatamente como eu comecei tb... MSX... A diferença é que um belo dia eu ganhei uma calculadora da sharp, se não me engano, que na verdade éra um dos primeiros pockets pcs da época, (ganhei de um amigo meu que achou a mesma num estacionamento da faculadade de engenharia. Quando ele anunciou que achou a bicha apareceram trocentos donos huahauha) programável, e em um derivado de basic tb... Agora, adivinhem como eu passava nas provas de matemática da escola???
|
|
|
|
|
eu realmente nao conheço o ivy mto bem mas acho difícil algo melhor que maven bem usado hj em dia....
|
|
|
|
Exato:
1- SEMPRE!!! Plano de negócios
2- Figurar dentro do seu plano de negócios PRINCIPALMENTE sua estratégia para entrar no mercado e captar clientes.
Hj o mercado de TI principalmente nas grandes empresas é monopolizado por grandes e milionários contratos, talvez vc encontre mercado nas menores.
|
|
|
|
|
eu tb estava algum tempo atrás procurando uma resposta para isso, acabei construindo via query mesmo...
|
|
|
|
|
na verdade uma solução um pouco mais inteligente, é se possivel, colocar um identificador único para essa tabela, mais ainda, a própria equipe do hibernate desencoraja a utilizaçao de chaves compostas. Para garantir a integridade neste caso, vc poderia usar hibernate-validator ou constraints do banco de dados.
|
|
|
|
|
Eu voto com o luca para algo baseado em messaging se possível. Alguns fornecedores mantém em suas ferramentas critérios de preferência para envio e recebimento de mensagens, segurança integrada, por exemplo... Conforme forem aumentando suas requisições vc vai aumentando os consumidores, paralelizando o processo.
|
|
|
|
Discordando de alguns pontos de vista: (Na verdade não acho que sejam pontos de vista, me parece mais informações que faltaram no resumo)
1- Nem sempre o maior benefício de SOA para as empresas é a integração. Na maioria das vezes o maior benefício é a agilidade na composição de distribuição dos serviços. Vide as ferramentas de BPMN que fazem "transformações automáticas" para fluxos BPEL, por exemplo. Tá certo que muito disso é socado goela abaixo pelos tool vendors.
2- Outra grande funcionalidade e na minha opinião uma das mais interessantes funcionalidades do ESB, é a pseudo-centralização dos serviços, que proporciona mecanismos para realização de auditorias, controle dos fluxos de mensagens, verificação mais simples e centralizada de gargalos, etc.
3- Segundo o que algém indagou sobre performance: Nao falei de performance pensando exatamente em ESBs, falei pensando emn SOA, devido ao overhead de processamento de xmls ( ou outro formato) de memória, e principalmente de I/O de arquivos texto em vez de streams. (embora para tudo isso exista algum paleativo)
4- quanto à utilização do BAM, que alguém citou, uma curiosidade: Va verificou a quantidade de memória que o BAM precisa para funcionar??? hehehe
|
|
|
|
Usa o que o amigo acima falou. É o melhor jeito.
|
|
|
|
eu não entendi bem o porque disso tudo ainda, MAS...
pense em usar:
replicação de DBMS, (hj em dia qqer SGBD que prestem e alguns que não prestam tem esse recurso).
2- Se não funcionar a gambi do hibernate, dá uma olhada no hibernate SHARDS. Ve se te ajuda...
Se eu soubesse exatamente o porque dessa distribuiçao do banco daria para ajudar mais. abs
|
|
|
|
|
Acredite, a maior gambiarra não é o código que vc terá que escrever. É quando esses IO´s que vc vai fazer nesse A3 despadronizado como o mesmo é tanto pelos fabricantes quanto pelas revendas, (ufa!) que vc vai ver porque nem é bom fazer a gabiarra.
|
|
|
|
|
Eu tenho! De maneira rápida, básica e clara, NÃO SE USA A3 EM SERVIDOR ALGUM!!! A NAO SER QUE O MESMO SEJA UM MÓDULO HSM.
|
|
|
|
|
|