Reinventado a roda? - Criando um WebProxy

4 respostas
D

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

@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);
}

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

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

[
  {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.

4 Respostas

C

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.

D

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.

C

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.

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.

D

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.

Criado 1 de novembro de 2008
Ultima resposta 4 de nov. de 2008
Respostas 4
Participantes 2