Alessandro, voce esta desinformado ou então mal intencionado…
[quote]Board of Directors
The Board of Directors is responsible for approving new specifications and final draft of specifications. It is their responsibility to ensure the overall quality of our specifications and that their architecture fits seemlessly together. Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year. Any member may nominate an individual or company to be a board member before an election.[/quote]
Curioso alguém dizer que este projeto REST-* é mantido pela comunidade sendo que ele mal existe ainda.
Não sou contra a criação de uma comunidade para discutir REST e boas práticas. Mas não vejo motivo em criar algo nos moldes do JCP. Principalmente liderado por uma empresa com nenhuma expressão no assunto.
Mochuara, rest-* foi uma iniciativa de Bill Buke, e ele lutou por isso dentro da Red Hat, acredite. Ele é mantido sim pela comunidade e conta com o feedback dos participantes. Existe regras para a formação do conselho, obviamente, e sendo iniciado por red haters, claro que a empresa tem cadeira permanente no conselho, assim como a Sun no jcp, o que não inviabiliza o processo.
Não entendi o ponto em questão. A comunidade mal existe e o projeto mal existe, ambos caminham juntos, isso é comum no meio open source. Mais curioso ainda é dizer que a empresa não tem expressão no assunto sendo criadora e mantenadora de uma das primeiras implementações JAX-RS e fomentar na comunidade Java a utilização do modelo Rest.
Volto a dizer, ser contra as idéias da especificação proposta e da própria comunidade é excelente através de argumentos técnicos, fomentar “discussão” sempre é bom. Infelizmente esse tipo de discussão esta cada vez mais difícil de encontrar.
[quote=Alessandro Lazarotti][quote=Leonardo3001]
Sabe qual a diferença entre as comunidades de C++, Python e Ruby e as comunidades de Java e .Net? Simples, as primeiras tratam os programadores como adultos, enquantos que os outros preferem (em sua maioria) ser infantilizados.[/quote]
Leonardo3001, não sei de seus problemas profissionais com a comunidade Java, birra com a linguagem, os times que você trabalhou ou que tem trabalhado, só sei que conheço muito profissional EXCELENTE desta mesma comunidade, onde sem exceção cada um deles cotribui de uma forma ou outra pela mesma. A comunidade não "trata" os desenvolvedores assim ou assado, a comunidade SÃO os próprios desenvolvedores, que guiam o norte. Você já leu alguma JCR? Participou de alguma discussão sobre as features de um novo release da linguagem com o grupo? Comitou drafts codes de algum proposal? É engajado em projetos open sources que possam ajudar essa comunidade? Então deixe de se colocar na posição "infantil", como você mesmo definiu, e ajude a mudar o quadro que você enxerga desta forma.[/quote]
Eu não disse ser infantil, mas ser infantilizado. A diferença é sutil, mas é importante. Vejo a comunidade Java mais como uma aristocracia, porque existem poucas empresas (e cada vez diminuindo à medida que as fusões acontecem) que tomam a maioria das decisões, e o restante simplesmente acata porque acredita que a nata está fazendo o melhor para todos, ou seja, se infantilizam. Claro que, como ninguém vigia os vigilantes, a nata toma decisões que são melhores para si.
É possível mudar? Dificilmente. Leio as mudanças propostas na JSR, e percebo que as mudanças visam a interesses das empresas envolvidas em vender alguma coisa. Os principais projetos open source são monstros administrados por organizações, onde: a) dependem de CGLIB ou ASM, que são coisas que um programador comum não conhece; e b) os principais mantenedores são empregados da própria organização. Para um programador Java, só é possível participar ativamente em Open Source em projetos marginais.
Portanto, é falsa a idéia de uma comunidade Java, seria até mais conveniente dizer sociedade Java.
Você conhece o trabalho do Bill Burke? Por acaso ele não é um desenvolvedor? Ja viu as discussões que estão na comunidade do rest-start.org… por acaso são sobre futebol? Veja a besteira que você esta dizendo, pois partindo de sua análise: "Para que criar um Grupo de Usuário Java com o braço-forte da Caelum?", e aqui esta o GUJ ajudando, através de várias pessoas independente de sua liagação com a escola!
Para sua informação, não é uma iniciativa da "Red Hat Inc." o projeto Rest-.org, assim como também não é o jbossbrasil.org aqui no Brasil uma iniciativa da RH. O projeto rest- foi iniciado pelos colaboradores do RestEasy e é mantido pela comunidade, se você não concorda com muita das propostas, pode colocar seu ponto de vista e agregar ao que esta tentando ser feito. Assim como no Brasil, o jbossbrasil.org é uma iniciativa aberta de utilizadores e colaboradores dos projetos JBoss, onde a Red Hat não possue ligação direta. O próprio projeto resteasy não é vinculado hoje com nenhum produto JBoss comercializado pela Red Hat.
Por falar nisso, diversos comitters de projetos jboss.org não tem vínculos com a Red Hat e não é preciso ir muito longe pra ver isso, como é o caso de um conhecido professor da USP (comitter do JBoss AS) ou do "Parser Man" brasileiro que é comitter do Drools, do Hibernate e membro do expert group do JPA 2.0. Sem citar pessoas que você provavelmente já escutou o nome, como o Dan Allen que não era funcionário da Red Hat quando já contribuia enormemente com a comunidade, com decisões e com o código do Seam Framework.[/quote]
O que eu vejo: um funcionário da JBoss resolve lançar uma iniciativa de padronização, utilizando um domínio de rede da JBoss, criando boas práticas sobre mensageria e 2PC, que são ofertados através de produtos da JBoss. Como eu não posso ver conflito de interesses nisso?
Não tenho nada contra a existência da JBoss, da SpringSource, da Oracle ou qualquer que seja. Mas me incomoda essa falta de transparência, e o grande poder dessas empresas sobre o destino do Java em relação aos demais envolvidos. Não seria muito mais fácil a JBoss simplesmente dizer: “tenho interesses em criar produtos em cima de REST e preciso de uma padronização que me beneficia”?
Ahh, então eu não consigo em um SLSB realisar transações 2PC? Claro que consigo
Mas eu acho que a resposta que vc quer ouvir, pode ser a do Bill Burke:
[quote=Bill Burke]"Transactions are not considered a REST best-practice. In fact, they are a REST anti-pattern. Needless to say, some environments do have transactional requirements. Even if not purely REST, these applications should be able to take advantage of RESTful principals when interacting with a Transaction Manager.
REST-* Transactions is a specification that attempts to define a RESTful interface for 2-Phase-Commit transactions. It describes the interaction between coordinator services and transaction participants as well as how transactions can propagate in distributed applications."[/quote][/quote]
Internamente, não importa se um serviço utilizar 2PC ou não. Se isso for transparente para os clientes, tudo bem. Da mesma forma que um SLSB pode realizar transação em dois bancos de dados, um POST numa URI também pode. O que desfigura o stateless é quando uma chamada de um serviço não configura “commitment”, seja um método de um EJB, seja um POST numa URI. E me parece isso que a “padronização” que propor.
Estou acompanhando de perto as especificações, por ora acredito que se quiserem contemplar todas as necessidades empresariais, como a citada - Atomicidade, depois segurança ( pois SSL é somente para point-to-point), REST vai deixar de ser simples.
WS*SOAP não ficou complexo à toa, era uma coisa muito simples e começaram a trazer o mundo de arquitetura distribuída como CORBA para dentro da especificação.
Eu não acredito em SilverBullet e SOAP já existe. Você pode endereçar necessidades com uma especificação e continuar com a simplicidade do REST para os casos mais triviais.
[quote=Kenobi]
Eu não acredito em SilverBullet e SOAP já existe. Você pode endereçar necessidades com uma especificação e continuar com a simplicidade do REST para os casos mais triviais. [/quote]
Eu também penso assim… mas é uma discussão boa, algumas coisas o próprio protocolo HTTP fornece, outras tem que ser implementadas na mão.
Você poderia citar exemplos de JSRs que “apenas” visam os interesses de empresas envolvidas em vender alguma coisa?
… será que essa não é uma opinião “pessoal” demais? Como já disse em outros posts aqui conheço “programadores java” que participam ativamente de projetos open sources de bastante destaque sem estar filiados a Oracle/IBM/RedHat/SpringSource. Qualquer pessoa pode contribuir com projetos Open Source. Se conhecer CGLIB for premissa para contribuir com um projeto, qual o problema? Será que conhecer uma ou outra tecnologia não é subjetivo demais “ao seu próprio conhecimento” para desmerecer as contribuições de algum projeto Open Source? Se você conhecesse CGLIB pensaria diferente… aliás, nem todos os projetos usam CGLIB não é mesmo?
Portanto? Pq você não contribui com o JCP ou pq você não conhece CGLIB ou ASM para contribuir com projetos Open Sources não marginais?
Importante salientar que: 1) o domínio jboss.org não tem vínculo comercial com linhas de produtos Red Hat, diferente por exemplo do domínio jboss.com. O mesmo acontece por exemplo com o fedoraproject.org 2)Não existe produto JBoss “comercializado” que envolva Rest… existe um projeto open source que é implementação da JAX-RS chamado RestEASY. Portanto a afirmação “que são ofertados através de produtos da JBoss” não faz sentido algum.
Quanto a transações e etc, releia as propostas e os drafts disponíveis na comunidade. Entenda que a questão varias vezes é realizar interface rest para vários serviços que não são naturalmente rest e podem se beneficiar da arquitetura.
Desculpa, esqueci de quotar no post anterior, vc disse (escreveu):
Sugiro que vc acompanhe a discussão na lista rest-discuss pra saber que toda a queixa se resume a esse ponto: A arrogância da JBoss de se colocar como autoridade na “padronização” do REST. A Sun não era só capacitada para exercer este papel como tb detinha os direitos da marca. Mas não é o caso com a JBoss. Tudo que ela fez sobre REST no mundo java foi um projetinho mixuruca de Servlet + URL Templates.
A verdade é que JAX-RS e suas implementações não colaram nem mesmo na comunidade Java! A maioria dos Restafarians Javaneses tinham adotado Restlet como framework REST preferido (e nem por isso o responsável pelo Restlet se achou no direito de propor tal absurdo).
Não sou contra a JBoss criar um wiki para reunir boas práticas sobre REST, mas não é essa a proposta inicial do REST-*. Alias, que péssima forma de se comecar um projeto.
[quote=mochuara]Desculpa, esqueci de quotar no post anterior, vc disse (escreveu):
[/quote]
Você novamente esqueceu de cotar um detalhe importante no que escrevi, mas vc deve saber disso:
Não é arrogância, é iniciativa. Ninguém é obrigado a seguir tais padrões assim como a Spring sempre não esteve aí para o JavaEE (bom, isso antigamente). O que muita gente não entendeu ainda é que a idéia não é engessar o Rest, mas discutir idéia de como solucionar problemas recorrentes no mundo corporativo, e isso não se restringe apenas a Rest mas a toda plataforma que possa fazer uso pelo menos de uma interface like REST, como componentes JavaEE. Não dá pra esperar a boa vontade de simplesmente “surgir”, sendo que as idéias já estão formadas na cabeça de alguém, como a de Burke. Um padrão só é padrão de fato se for seguido, portanto o tempo dirá se vingará ou não o projeto, simples…
Quanto a projetinho mixuruca, bom isso é opinião pessoal sua novamente, felizmente muita gente, mas muita mesmo, usa RestEASY na comunidade Java e isso afirmo com segurança e com base.
Desculpe, mas isso esta muito vago. Você tem esses dados? JAX-RS não pegou? De onde vem essa afirmaçào?Qual percetual de pessoas que usam Restlet comparados a quantas usam Jersey e RestEASY ou CFX? Não estou te atacando, é uma curiosidade que fiquei mesmo
PS: alias, assim como o Hibernate se alinhou a implementação do JPA com sua extensão Hibernate EntityManager, o Restlet tbm tem sua extensão JAX-RS de alinhamento com o padrão.
