Reinventado a roda? - Criando um WebProxy

Galera,

Estou abstraindo uma forma de utilizar alguns serviços web especialmente para operações CRUD com AJAX, mais precisamente EXTJS.

Ai bolei um esquema de WebProxy e gostaria de saber a opinião de vocês. Como é um projeto prova de conceito, pode evoluir ou não.

Princípio:

  1. Você cria suas Entidades e SesssionBean (EJB3 por enquanto) para manipular essas entidades da forma que você gosta de fazer;
  2. Mapeia esse SessionBean em uma arquivo de configuração, dando um nome para a “Sessão” e configura um Serializer, que é responsável por transportar os get/set do Bean (Entity) em valores.
  3. Acessar os métodos do SessionBean via REST.

Eu sei que tem muito o que fazer: segurança, validação, etc etc. Mas quero um feedback sobre o conceito.

Exemplo:

SessionBean

[code]@Local
public interface IFinanceLocal {

public void addAsset(Asset asset) throws FinancialException;
public void removeAsset(Asset asset) throws FinancialException;
public List<?> getAssets();
public void addAccount(Account account) throws FinancialException;
public void removeAccount(Account account) throws FinancialException;
public void updateAccount(Account account) throws FinancialException;
public List<?> getAccounts();
public Account getAccount(Integer id);

}[/code]

Arquivo XML de configuração

<session-proxy> <session name="finance"> <alias name="fin"/> <entity class="com.sarbarian.finance.entity.Account"/> <serializer class="com.sarbarian.webproxy.serializer.JsonSerializer"/> <factory> <param name="session.class" value="com.sarbarian.finance.IFinanceLocal"/> <param name="factory.class" value="com.sarbarian.webproxy.EJB3StatelessFactory"/> <param name="ejb3.interface.type" value="local"/> <param name="ejb3.interface.name" value="jboss5-dev/FinanceSession/local"/> </factory> </session> </session-proxy>

Resultado

http://localhost:8080/com.sarbarian.webproxy/wp/finance/getAssets

[ {id:1, description:"description1", name:"nameasset", class:"com.sarbarian.finance.entity.Asset", code:"code1"}, {id:2, description:"description1", name:"nameasset", class:"com.sarbarian.finance.entity.Asset", code:"code1"} ]

Entenderam? - Muita coisa pode ser feita com WebService etc. Mas o lance aqui é LESS CODING, ou seja, faça apenas o SessionBean, mapeie minimamente, e deixe o Proxy conectar a lógica na sua camada de apresentação.

O que me dizem? Estou reinventando a roda ou isso é inovação (usar velhos conceitos para coisas novas).

PS: O código fonte é apenas para vocês verem a mecânica…

Abraços,

Davi.

O que vc esta fazendo se chama RPC (sobre HTTP), tao diferente de REST que chega ser considerado o oposto. Por isos nao entendi como REST foi parar na descricao do seu projeto.

RPC != REST

Repare, nao estou dizendo que vc precisa estar de acordo com a arquitetura REST. Frameworks evoluem da solucao de um problema, se esse problema inicial passa por distribuir objetos apenas nao vejo como REST pode ajudar no caso.

Humm, posso ter usado de forma equivocada o termo REST então. É que na verdade, gosto do padrão da URL que o REST proporciona.

/a/b/c/d etc…

Sim, estou fazendo RPC, mas veja que não estou precisando construir classes específicas que fariam o RPC pra mim, e sim, “on-the-fly”, permitindo RPC a partir de classes já existentes para finalidades um pouco diferentes. Sei que poderia criar facilmente um WebService com @notations, mas teria que construir um webservice para cada nova funcionalidade utilizada, compilar as classes e fazer deploy do contexto, o que pode ser complicado para sistemas com muitas entidades e métodos…

Hoje é EJB3, amanhã pode ser para operações em LDAP, POJO, qualquer outra coisa…

Abraços,

Davi.

[quote=dbht]Humm, posso ter usado de forma equivocada o termo REST então. É que na verdade, gosto do padrão da URL que o REST proporciona.

/a/b/c/d etc…

Sim, estou fazendo RPC, mas veja que não estou precisando construir classes específicas que fariam o RPC pra mim, e sim, “on-the-fly”, permitindo RPC a partir de classes já existentes para finalidades um pouco diferentes. Sei que poderia criar facilmente um WebService com @notations, mas teria que construir um webservice para cada nova funcionalidade utilizada, compilar as classes e fazer deploy do contexto, o que pode ser complicado para sistemas com muitas entidades e métodos…

Hoje é EJB3, amanhã pode ser para operações em LDAP, POJO, qualquer outra coisa…

Abraços,

Davi.[/quote]

Mas a questao de ser a/b/c/d ou t/y5/34 é meramente estetica e nao serve como indicador de restfulnabilidade(!).

O problema da URL …/finance/getAssets é a informacao do metodo que esta na url e nao no protocolo. O fato do metodo ser definido no protocolo e nao pelo usuario e uma das principais caracteristicas do REST, é o que se chama Interface Uniforme. No caso de REST sobre HTTP temos GET, POST, PUT e DELETE. Quando o metodo HTTP utilizado é o GET vc nao precisa (nem deve) repetir essa informacao na url, fica apenas …/finance/assets.

Alem disso seria interessante representar os relacionamentos dos objetos tb por meio de URLs de forma que a responsabilidade de carregar as associacoes ficaria a cargo do cliente. Como os metodos ja existem o processo de modelagem resulta no que chamamos de resources e nao mais objetos, mas a principio nao importa, apenas nao definimos os metodos eles ja pertencem ao protocolo.

Para acessar Assets e cada Asset na colecao:

…/finance/assets
…finance/assets/34

Novamente, poderia ser uma url nao amigavel, importante do ponto de vista REST e que exista pelo menos uma para identificar o resource/objeto.

O mesmo GET acessa assets e cada asset na colecao, sem serializacao do objeto em si, mas atraves de uma representacao das informacoes (links inclusive) em um formato json ou xml.

Vou pensar melhor sobre as suas ponderações, obrigado.

Porém, utilizando a URL finance/assets/34 pressuponho que tenho um método getAssets(Long id). E se tenho esse aqui:

getAssets(Long id, String category), farei isso: finance/assets/34/stocks ?

Mas o importante acima de tudo não é criar um framework REST, e sim, integrar mais facilmente a camada de negócio com a de apresentação, especialmente utilizando interfaces web com ajax.

Abraços,

Davi.