REST x RMI

[ElemarJR]

Olá pessoal, como estamos?

A cada dia fica mais evidente a necessidade de expormos mecanismos de
integração mais ricos para nossas aplicações. Muitos sistemas já
disponibilizam suas funcionalidades como serviços para que estes
possam ser combinados com outros abrindo uma rica gama de
possibilidades de composição maximizando a entrega de valor para os
clientes.

Dentre as abordagens para exposição de serviços, duas correntes de
pensamento arquitetônico distintas ganham bastante força: REST e RMI.

Minha proposta é discutirmos nossas experiências na adoção de cada uma
dessas linhas de forma que possamos compartilhar dificuldades e
facilidades encontradas.

Além disso, gostaria de ter alguma idéia sobre quantos de vocês
implementam efetivamente SOA.

[]s

Elemar Jr
@elemarjr

[Alexsandro_xpt]

Eu com "RMI". Remote Method Invocation?

[Vinícius Hana Scardazzi]

Não conhecia RMI, dei uma estudada bem rápida então entendam se eu falar alguma besteira.

Achei o mesmo relativamente parecido com o funcionamento do WCF. Tão de acordo?

Tenho que pensar um pouco melhor pra poder dizer algo relevante quanto as diferenças de ambos.

Quanto a usar SOA, onde trabalho temos que nos comunicar com diversos web services diferentes de N provedores. Os mesmos trazem informações sobre a mesma coisa (sem repetições, são complementares), mas obviamente as formas de se comunicar são muito diferentes entre cada web service.

Como temos diversos sistemas que precisam dessas informações, encapsulamos em um serviço WCF a obtenção e tradução desses diferentes padrões em um padrão único, definido por nós mesmos. Assim, temos um serviço que obtem essas informações sem precisar repetir essas lógicas em cada consumidor, e os consumidores trabalham com esse padrão definido por nós mesmos sem depender de nenhuma informação específica de algum provedor.

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Alberto Monteiro]

OData também não seria uma opção?

[Rafael Mueller]

OData não fornece o mesmo nível de desacoplamento entre cliente/servidor que o rest fornece.

http://stackoverflow.com/questions/2458407/difference-between-odata-and-rest-web-services

Att,

Rafael

2011/4/27 Alberto Monteiro <betim...@gmail.com>

[Pedro Reys]

Oi Elemar,

Você pode me explicar melhor o que é RMI? É um outro nome pra RPC? Se sim, não gosto muito não :)

Não gosto de RPC por esta, normalmente, deixar pouco explicito o fato de que a chamada é remota o que acaba fazendo com que as pessoas acabem caindo em algumas das falácias da computação distribuída.

Aqui na Headspring temos em um projeto um serviço exposto via HTTP, mas que eu não definiria exatamente como ReST, embora use o Restfulie, Acho que estaria no nível 0 do Modelo de Richardson. Enfim, usamos HTTP como protocolo, mas não usamos propriamente o conceito de Resource, por exemplo. É um POX, na verdade.

Isso leva a um problema que vejo nas discussões hoje em dia. Sei que muitas APIs por ai, que funcionam como essa nossa, apenas por usarem os métodos HTTP, são chamadas de RESTFul apis, o que acaba causando mais confusão. Acho que o termo REST, hoje em dia, já acabou perdendo parte do sentido. 

O que é mais raro de se encontrar nas ditas RESTFul apis que vemos por ai, eu acho, é a utilização, de fato, da hypermedia. Ainda estou pra ver uma api pública que implemente HATEOAS, infelizmente. 

Com relação ao uso de SOA, posso dizer que de certa maneira temos alguns projetos aqui que usam sim uma Arquitetura orientada a serviços. Não necessariamente web services, mas temos muitos projetos que utilizam, e muito, o NServiceBus, sendo alguns destes projetos usando CQRS e Event Sourcing.

Nossa, acho que atingi o nível máximo permitido de siglas em um único email, espero não ter disparado o bullshitômetro de muitos. :P

Abraços,

- Pedro Reys

2011/4/27 ElemarJR <elem...@gmail.com>

[Vinicius Quaiato]

*acho* que está rolando em brasília o "Soa Symposium": http://www.soasymposium.com.br/

2011/4/27 ElemarJR <elem...@gmail.com>

[Elemar Junior]

Opa pessoal,

Foi publicado o podcast do grupo sobre SOA. Foi um papo muito bacana em que tive a honra de participar.

Está em: http://podcast.dotnetarchitects.net/2011/04/podcast-17-soa

Parabéns ao Brandão pela edição.

[]s

Elemar JR

@elemarjr

[Sidney Lima Filho]

Pedro, sera que cair na falácia de computação distribuida está no caso do MAL entendimento do conceito de RPC? Se abstrairmos para o nivel de network, REST não seria um RPC? Eu enxergo que a internet se baseia toda em RPC, pois se todo recurso for um procedimento, e nesse caso estou me referindo a definição de procedimento, então temos que URL poderia ser um UPL (Uniform Procedure Locator). 

Quando trabalhamos com REST nada mais fazemos do que realmente tratar os procedimentos como recurso, claro que quando se trata de um nivel 3 de REST já começa a entrar em conceitos que o velho RPC não possuia, mas também só existe graças a Web, ao invés da Internet.

IMHO, REST nada mais é do que uma das formas de RPC/RMI, de forma extendida. Pois todas elas possuem o conceito de acionar algum recurso remoto, com diferença de ser via protocolo HTTP.

REST Nivel 0 = RPC

REST Nivel 1 em diante = RMI

A diferença principal entre RPC e RMI é que o RPC dá uma enfase arquitetural ao VERBO, quando o RMI dá uma enfase ao SUBSTANTIVO, da mesma maneira que o REST trata a partir do Nivel 1.

Ao ver essa thread do Elemar eu comecei a questionar o como expor uma arquitetura RMI vs REST. Como estamos num grupo de .NET vou falar com as tecnologias OK?

Para mim comparar uma arquitetura RMI vs REST é como se eu comparasse a arquitetura de uma aplicação WindowsForms de intranet que usa Remoting e uma aplicação Web de autenticação que disponibiliza uma API através de URL's. Até posso usar uma integrada a outra mas no contexto de cada aplicação uma arquitetura é mais natural (se é que posso usar essa palavra) do que a outra.
                                                                         
Sidney Lima Filho
Vivina Softhouse
http://vivina.com.br | @sidneyfilho

2011/4/27 Pedro Reys <pedr...@gmail.com>

[Rafael Mueller]

Acredito que RPC e Rest não são tão parecidos.

RPC usa o HTTP apenas como uma forma de transporte, enquanto Rest realmente abraça o HTTP e usa ele como seu core.

Grato,
--
Rafael Mueller

2011/4/29 Sidney Lima Filho <sidney...@vivina.com.br>

[Sidney Lima Filho]

Rafael, eu vejo RPC como um conceito e REST também, independente da tecnologia de transporte, quer ver um exemplo?

Quando temos serviços disponibilizando recursos assim: 

EX1: http://localhost/controller/Manager/GetEmployees?CompanyId=1       

Tem cara de RPC pois ele dá uma enfase no Verbo, o recurso é o Verbo

EX2: http://localhost/controller/EmployeeManager?action=Get&CompanyId=1                           

Está com jeitão de REST, mas se eu uso o POST Verb apenas para evitar cache, como vejo muitas pessoas fazendo, ainda é um REST Nivel 0

O Velho RPC, da época de CORBA & cia, se baseava apenas na invocação de um método remoto, que com o surgimento da Web as pessoas continuam a fazer mas com URL's.

Note que REST é uma forma de RPC, mas RPC não é REST. O REST é como um RPC onde os operadores de protocolo são POST, GET, PUT, DELETE, etc.

Na época de programação estruturada só podia invocar procedures remotamente, afinal só tinha isso para executar mesmo. Mas com o avanço do desenvolvimento para orientação a objetos por exemplo, começou-se a falar de RMI, onde poderiamos utilizar os objetos em outras maquinas com suas regras ocultas, mantendo o estado nesta mesma maquina. Agora com REST você não mantem mais o estado você transfere ele e representa na comunicação, é uma mudança de paradigma, não enxergar mais os dados cru, mais na raiz do "Don´t Ask, Tell me".

                                                                         
Sidney Lima Filho
Vivina Softhouse
http://vivina.com.br | @sidneyfilho

2011/4/29 Rafael Mueller <muell...@gmail.com>

[Phil Calçado]

Oi, Sidney,

2011/4/30 Sidney Lima Filho <sidney...@vivina.com.br>:

> EX2: http://localhost/controller/EmployeeManager?action=Get&CompanyId=1
>
> Está com jeitão de REST, mas se eu uso o POST Verb apenas para evitar cache,
> como vejo muitas pessoas fazendo, ainda é um REST Nivel 0

Por que está com jeito de REST? Olhando apenas a URI acima, incluindo
os parâmetros, isso é apenas RPC sobre HTTP para mim.

> Note que REST é uma forma de RPC, mas RPC não é REST. O REST é como um RPC
> onde os operadores de protocolo são POST, GET, PUT, DELETE, etc.

REST não é uma forma de RPC, as abstrações são muito diferentes. Em
RPC você envia um comando para o servidor remoto dizendo "me execute a
função X". O fato que a função X retorna uma lista de objetos é
detalhe de implementação e opaco para o protocolo e estilo
arquitetural utilizado. A única coisa que se conhece é que funções são
executadas,a semântica da execução não é conhecida. Em REST você tem
recursos, que são o coração dos serviços, e uma série finita de
operações que atuam nestes recursos. O estilo arquitetural permite que
recursos sejam interligados facilmente via URI e o uso de verbos
padronizados permite que diversos recursos não-funcionais sejam
implementados pela infra-estrutura.

Comparar um estilo REST com RPC é semelhante à comparar programação
procedural com funcional ou orientada a objetos. Todos estes
paradigmas fazem a mesma coisas, definida por Turing, mas as
abstrações que eles se baseiam e eventual estilo arquitetural e de
design que deriva destas abstrações são completamente diferentes e
muito importantes.

O livro do Jim Webber
(http://www.amazon.com/REST-Practice-Hypermedia-Systems-Architecture/dp/0596805829)
possui explicações bem acessíveis sobre estes conceitos.

[]s

--
Phil Calçado
http://fragmental.tw
http://www.fragmental.com.br

[Giovanni Bassi]

Sinceramente eu evito distribuir a aplicação ao máximo. WCF funciona muito bem pra muitos cenários, e é uma forma de RPC, mas não de RMI. O antigo .NET Remoting era uma forma de RMI (que pra mim a Microsoft só fez pros Javeiros não dizerem que não tinha, ops, quer dizer, tinha o DCOM, né? Faz teeeeeempo...). Entendo que boa parte das aplicações do .NET vai viver tranquilamente no WCF (e RPC, já que WCF não foca muito no REST) quando precisarem distribuir porque é só uma forma de fazer isso, e entre trabalhar com REST ou RPC há prós e contras em cada um (como em quase tudo na vida), mas a plataforma claramente favorece o RPC, quando pensamos no que é fornecido e evangelizado pela Microsoft.

A opção para o REST são os frameworks open source que completam e facilitam isso. o Restfulie, por exemplo, é uma opção legal.

Outro ponto de vista interessante é que trabalhar na web com Javascript com REST é dez vezes mais fácil que com RPC (e WCF). Daí não vou discutir, vou com REST.

Mas de .NET pra .NET, pra grande parte dos cenários não fará grande diferença e eu iria com o padrão pra diminuir custo futuro de manutenção, apostando que a maioria conhece WCF e a minoria não conhece nem mesmo o que é REST, quanto mais um Restfulie.

2011/4/27 ElemarJR <elem...@gmail.com>

[Rafael Mueller]

Acho que a última versão do WCF mudou muito sobre não ter foco em REST.

Glenn Block está palestrando e escrevendo bastante sobre WCF + REST http://www.google.com/search?q=wcf+rest+glenn 

Contudo acho que o WCF ainda tem que andar bastante pra ficar mais interessante, hoje a melhor opção REST na plataforma .net, IMO, é o http://openrasta.org/ 

Na versão 3 (que está saindo do forno) o Sebastien deu mais foco em hypermedia e convenções. http://skillsmatter.com/podcast/open-source-dot-net/lambla-openrasta3

Além do livro do Jim, recomendo RESTful Web Services http://oreilly.com/catalog/9780596529260 o livro é de 2007 mas é muito bom.

Grato,
--
Rafael Mueller

2011/5/2 Giovanni Bassi <gig...@giggio.net>

[Pedro Reys]

De fato, o Glenn está fazendo um trabalho bem legal com a WCF Web Api

- Pedro Reys

2011/5/2 Rafael Mueller <muell...@gmail.com>

[Pedro Reys]

Um post interessante do Roy Fielding: REST APIs must be hypertext-driven 

- Pedro Reys

2011/5/2 Pedro Reys <pedr...@gmail.com>