What's HOT and what is NOT - 1o Semestre 2008

pcalcado:

continuando…

A regra é clara:

[b]

• até 5 tecnologias/técnicas/coisa do gênero que vão causar barulho nos próximos 12 meses.
• até 5 tecnologias/técnicas/coisa do gênero que vão começar a afudnar ou sumir de vez nos próximos 12 meses.[/b]

pcalcado,

acho que só ocorreu um errinho nesta “enquete”. O assunto temos “What’s HOT and what is NOT - 1o Semestre 2008”, e vc pede para colocar as coisas que vão bombar ou afundar em 12 meses, na verdade seria nos próximos 6 meses.

abç

Por quê?

:thumbup: A Microsoft se rendendo ao blu-ray da Sony vai ser impagável.
:thumbup: As empresas de 3 letrinhas tentarão adotar metodologias ágeis em conjunto com conceitos falidos como fábricas de software(o que já acontece em uma grande empresa de 3 letrinhas), e isso fará com que projetos e mais projetos afundem e jogarão a culpa nas metodologias ágeis.
:thumbup: JRuby e Grails talvez entrem para o mainstream se continuar evoluindo rápido e seu uso dentro das empresas se tornará uma realidade.
:thumbup: RIA
:thumbup: Java 7

:thumbdown: XBOX 360
:thumbdown: SOA
:thumbdown: RUP
:thumbdown: JSF e JPA

1 semestre = 6 meses

Foi mal, na verdade acho que eu não prestei atenção. Esta é a enquete do 1º semestre, e não sobre o 1º semestre, não é isso ? :?:

Exato

:thumbup: Behaviour Driven Development
:thumbup: Arquiteturas baseadas em REST
:thumbup: LOP
:thumbup: Erlang, Scala e concorrência em geral
:thumbup: Outras linguagens assaltando a JVM

:thumbdown: linguagem Java
:thumbdown: SOA e SOAP em geral
:thumbdown: RIA firulado - é igual a sexo na adolescência, todo mundo fala mas ninguém faz, tudo continua sendo html + ajax
:thumbdown: Scrum e CMMI de jeans
:thumbdown: Apple - início de ano fraquísimo

:thumbup:RESTfull
:thumbup: RIA
:thumbup: SOA
:thumbup: Linguagens dinâmicas(Groovy, Ruby, etc)
:thumbup: GlassFish

:thumbdown: JavaFX
:thumbdown: Metodologias Engessadas
:thumbdown: Seam
:thumbdown: Frameworks Web

• Google throws Orkut
• Groovy on rails!
• Ubuntu
• JSF
• REST

:evil:

• .NET
• JavaFX
• Vista, Windows.
• Netbeans

:thumbup: Behaviour Driven Development
:thumbup: Arquiteturas baseadas em REST
:thumbup: Integracao continua
:thumbup: JRuby e Rubinius
:thumbup: NetBeans (parecem finalmente estar adicionando features coerentes)

:thumbdown: Linguagem Java
:thumbdown: SOA e SOAP em geral
:thumbdown: RIA (nunca foi ‘hot’, IMHO)
:thumbdown: Eclipse (ta virando uma bola de neve)
:thumbdown: IntelliJ (idem ao Eclipse)

pq a linguagem java :thumbdown: ?

bem la vai o que eu acho:

:thumbup: oracle
:thumbup: Java 7
:thumbup: jsf
:thumbup: netbeans
:thumbup: nintendo wii
:thumbdown: eclipse
:thumbdown: Ruby (não confio em ruby)
:thumbdown: Struts 1
:thumbdown: XBox 360
:thumbdown: Playstation 3

:thumbup: Ruby
:thumbup: JRuby
:thumbup: REST
:thumbup: BDD

:thumbdown: Eclipse
:thumbdown: Netbeans
:thumbdown: SOAP
:thumbdown: Linguagem Java
:thumbdown: SOA

:thumbup: JRuby
:thumbup: CSRF (aqui e aqui )
:thumbup: BDD
:thumbup: DSL’s (lançamento do livro do Fowler)
:thumbup: git

:thumbdown: IDE’s pesadas e lentas
:thumbdown: PMBoK
:thumbdown: SOA
:thumbdown: RIA
:thumbdown: CMMI/MPS.BR

:thumbup: GIT
:thumbup: Integracao continua
:thumbup: Rubinius, JRuby (mundo ruby)
:thumbup: Linguagens Dinamicas na JVM
:thumbup: Google

:thumbdown: JSF
:thumbdown: JavaFX
:thumbdown: CMM/MPS.BR/PMBOK
:thumbdown: SOAP
:thumbdown: Waterfall

• Scala, Ruby e Groovy
• Melhora nos plugins (IDE’s) de desenvolvimento para as linguagens acima
• Wicket / Databinder
• JPA/Hibernate (será que frameworks orm mais simples podem ganhar espaço? :roll: )

:?

• JSF e Seam
• SOA
• JavaFX

Sobe
[list]Rubinius[/list]
[list]Arc[/list]
[list]Glassfish[/list]
[list]Python 3[/list]
[list]Uma, e somente uma dessas opções: JRuby, Groovy, Rhino, Scala (mas não arrisco ainda qual)[/list]

Desce
[list]PHP[/list]
[list]Internet Explorer 6[/list]
[list]mudanças drásticas em Java[/list]
[list]os termos “agile” e “open source” - ambos estarão completamente desprovidos de significado até o final do ano[/list]

Bônus: Fenômeno interessante que eu não sei pra que lado vai
[list]startups de fim-de-semana[/list]

:thumbdown: Esses vão se dar mal:
Ruby on Rails
Maker
JavaFX
Maker
Flash
Maker
Microsoft
Maker
Tudo que estiver relacionado a XML
Maker
Closures
Maker

E também o Maker.

E esse vai se dar mal de novo: Corinthians.

Ops, faltou alguma coisa rs

:thumbup: Internal DSLs em Ruby

:thumbdown: [A-Za-z]{3}

:lol: EJB3
:lol: RESTful (ou não) Applications (basta acabarem com o SOAP)
:lol: Modernização dos Frameworks JS
:lol: Annotations! ( :arrow: Será que as empresas grandes vão deixar de usar Java 1.4? Acredito que sim!)
:lol: Java 7 e suas novas features (tirando o suporte nativo a XML)
:lol: Glassfish

:x JSF (Afinal, ele nunca decolou, vamos ser realista)
:x Seam (Tudo ligado ao JSF vai pro mesmo saco)

:thumbup: SOA

:thumbdown: Frameworks Web
[/quote]

Concordo que SOA não mostra nenhum sinal de desaceleração, por mais que a vanguarda esteja adotando REST. Mas frameworks web? Essa eu não entendi.

SOBE

• Varias linguagens na JVM
• Integracao continua (cada vez mais o pessoal está tomando conhecimento sobre isso)
• Testes de uma maneira geral (cada vez mais o pessoal está tomando conhecimento sobre a importancia disso)
• NetBeans (não é minha IDE preferida, mas está ganhando novos adeptos)
• Glassfish 3

DESCE

• Struts 2
• Microsoft
• .NET
• JavaFX
• Java 7 (Vai virar um monstrinho? …não sei)

rubinelli:

Rafael Nunes:

:thumbup:RESTfull
:thumbup: SOA

:thumbdown: Frameworks Web

Concordo que SOA não mostra nenhum sinal de desaceleração, por mais que a vanguarda esteja adotando REST. Mas frameworks web? Essa eu não entendi.

Em relação ao SOA, por mais que não seja tão suave e prática a implementação, os grandes players estão investindo ainda no crescimento e utilização de ferramentas para implementação de SOA, e creio que depois de gastarem tanta grana, vão continuar colocando guela abaixo dos clientes.

Frameworks web me refiro a Struts, WebWork, SpringMVC. Acho que JSF tem boas chances de crescer. Além de outras alternativas como Ruby ou Flex.

:thumbup: DSLs
:thumbup: Concorrência
:thumbup: BDD
:thumbup: XMPP
:thumbup: DLR

:thumbdown: Linguagem Java
:thumbdown: REST (houve muito barulho sobre o assunto em 2006 e 2007. Em 2008, o barulho tende a diminuir já que REST não vai mais ser novidade para ninguém. Mas ainda é um tópico interessante )
:thumbdown: WS-*
:thumbdown: BPM
:thumbdown: EJB (2.X/3.0)

Daniel Quirino Oliveira:

:thumbdown: Linguagem Java
:thumbdown: REST
:thumbdown: SOA
:thumbdown: BPM
:thumbdown: EJB (2.X/3.0)

Seria quase que a morte dos bilhoes de dolares investidos nos ultimos 2 anos pelas grandes empresas?!?
Acho que a força do dinheiro ainda vai falar mais alto nesse especto…

:lol:

Eles investiram porque quiseram

Mas o caminho pra SOA é morrer mesmo, não tem muito pra onde correr não, só vai se manter enquanto houverem empresas jogando dinheiro no buraco negro.

Não tenho autoridade para defender, mas qual o grande problema de SOA para estarem tão contra isso ?

Olá

Desculpe-me mas vou discordar. SOA é um nome de algo parecido ao que já se fazia antes de inventarem o nome e que continuarão fazendo mesmo com outro nome.

[]s
Luca

pessoal, eu so meio leigo e iniciante em web, o que me dexa por fora da maioria do mercado, então desculpem minha ignorancia desde ja, mais peço que quem disse isso por favor explique o por que:

pq linguagem java para descer??? linguagens dinamicas como ruby vão toma mercado assim bruscamente a ponto de roba tanto assim o mercado de java??? java tem a parte da integração até que legal, sera q isso não vai contar?

não conheço de jsf mais… eu vi alguns comentarios falando que ele é simples, por aqui pelo guj, ouvi que ele é bom, coisa assim, masi que o pessoal ainda anda exigindo que os programadores trabalhem com struts, e o 1, não o 2… é por causa disso mesmo q jsf apesar de ser bom assim não vai alavanca??? (tenho certo interesse pq quero aprender a usar algum framework bom pra web)

Não é só a questão de nomeação… o Taurion coloca toda edição uma coluna sobre SOA na Mundo Java. Todas as empresas estão “começando” a ter uma plataforma orientada a serviços… acho que esse apocalipse vai demorar um pouco mais… se fosse por novas tecnologias, grandes empresas já teriam largado o COBOL/CICS a muito tempo…

Luca:

Olá

Desculpe-me mas vou discordar. SOA é um nome de algo parecido ao que já se fazia antes de inventarem o nome e que continuarão fazendo mesmo com outro nome.

[]s
Luca

uhum…

curioso que, uma certa empresa que trabalhei tinha uma puta arquitetura de mensageria, permitindo a comunicação entre vários sistemas internos. A empresa, ainda assim, tem planos de migrar pra SOA. Sabe como é, né: “eles querem usar webservices”.

Luca:

Olá

Desculpe-me mas vou discordar. SOA é um nome de algo parecido ao que já se fazia antes de inventarem o nome e que continuarão fazendo mesmo com outro nome.

[]s
Luca

Ok, então acho melhor explicar meu ponto sobre SOA. Concordo com você que SOA é feito desde o momento em que mais de uma aplicação passou a existir dentro de alguma organização. Mas o que eu estou apostando que vai decair é a história de que SOA só existe com WS-*, que é mais ou menos o discurso que os fornecedores usam para vender suas soluções caríssimas de integração.

Olá

Java vai diminuir seu domínio justamente porque o Rails comerá um bocado do espaço. Mas a web continuará crescendo e a demanda por aplicações Java ainda será enorme. Pode estudar Java que ainda é um bom investimento. E estude também Ruby & Rails pois vale a pena mas nem de longe o uso de Ruby será maior do que o de Java nos próximos anos.

[]s
Luca

Agora a coisa ficou mais clara.
Também não é por que eles alegam isso (afinal não sabem o que é SOA) que nós vamos interpreta-los assim.

Dai eu concordo.

:thumbdown: WS-*

Olá

Apesar de achar que os vendedores são muito fortes e ainda venderão seus elefantes brancos por muito tempo, neste contexto você tem razão e eu sei bem disto. Uma vez e não faz muito tempo, me procuraram para trabalhar com integração de sistemas que é coisa que já fiz muitas vezes. Na verdade eles procuravam um cara para pilotar a ferramenta deles e nisto eu não tinha a menor experiência. Como estou a perigo, não se surpreenda se um dia me vir fazendo isto e ainda convencendo o cliente que vendor lock-in é tudo que o cliente precisa… :roll:

[]s
Luca

Exatamente, SOA no sentido de se utilizar ferramentas WS-* é um retrocesso e uma complicação desnecessária, é só olhar e perceber que os mais utilizados web services do mundo são baseados em REST ou POX, só quem não tinha coisa melhor pra fazer correu pra web services baseados em soap e mesmo assim a maioria dos web services baseados em SOAP públicos tem versões REST/POX que são bem mais utilizados, como os web services de e-commerce da Amazon.

:thumbup: Erlang + Erlyweb
:thumbup: GWT + TinyRails + JRuby (palpite psicodélico)
:thumbup: REST
:thumbup: Seaside
:thumbup: Rubinius

:thumbdown: Linguagem Java
:thumbdown: MRI / YARV
:thumbdown: [a-z]{3}
:thumbdown: CMMI
:thumbdown: Clientes das [a-z]{3} :twisted:

t+

Proteu Alcebidiano:

:thumbdown: Linguagem Java
:thumbdown: MRI / YARV
:thumbdown: [a-z]{3}
:thumbdown: CMMI
:thumbdown: Clientes das [a-z]{3} :twisted:

Vc acha mesmo que as consultorias [A-Za-z]{3} vão morrer mesmo por causa da sua metodologia?!?!? Tem certeza?!?!? Mas do fundo do seu coração mesmo?!?!?
E o CMMI for Acquisition, que é um dos modelos de CMMi?!? Vc acha que as empresas vão comprar hardwares por metodologias ageis tambem?!?!? Jura?!?
E pior sobre as [A-Za-z]{3}, os clientes delas vão falir por causa das consultorias que utilizam metodologias que não são ageis?!?!?

P.S.: É, cv, o seu [A-Za-z]{3} pegou mesmo!

Bons , ae seguem os meus :

:arrow: RIA de forma decente - SilverLight, Flex e afins ( Olhem tb para frameworks como GraniteDS) !!.
:arrow: DSL´s e Engines de regras como Drools
:arrow: BDD , metodogias ágeis
:arrow: Linguagens dinâmicas para VM - Groovy, Ruby entre outras.
:arrow: Linguagens para concorrência e específicas como Erlang,Scala e Lua para games
:arrow: CEP, OSGI e SCA ( acredito que de outra forma, como o Luca disse, vão continuar a fazer as mesmas coisas, de outra forma).

Desce:

:arrow: C#, está virando uma coisa de doido.
:arrow: CMMI, PMI e afins
:arrow: Laszlo , Ajax
:arrow: Spring, Frameworks complexos java para Web
:arrow: UML, MDA, Maven e Menta (sacanagem hein SAOJ ? )

rodrigoallemand:

Vc acha mesmo que as consultorias [A-Za-z]{3} vão morrer mesmo por causa da sua metodologia?!?!? Tem certeza?!?!? Mas do fundo do seu coração mesmo?!?!?
E o CMMI for Acquisition, que é um dos modelos de CMMi?!? Vc acha que as empresas vão comprar hardwares por metodologias ageis tambem?!?!? Jura?!?
E pior sobre as [A-Za-z]{3}, os clientes delas vão falir por causa das consultorias que utilizam metodologias que não são ageis?!?!?

P.S.: É, cv, o seu [A-Za-z]{3} pegou mesmo!

Tem gente que está falando com o coração e não com a cabeça. Depois que você vê falarem em “agile waterfall” a sério, como eu vi, você começa a perder a fé na humanidade…

CMMi, PMI, ITIL, WS-Deathstar, ESB, e a construção de pirâmides tecnológicas que não têm outro propósito senão exaltar o poder dos projects sponsors nos acompanharão por muito tempo ainda.

Eles investiram porque quiseram

Mas o caminho pra SOA é morrer mesmo, não tem muito pra onde correr não, só vai se manter enquanto houverem empresas jogando dinheiro no buraco negro.[/quote]
Exatamente. Saca só o drama da empresa onde trabalho atualmente …
http://emerleite.wordpress.com/2008/02/15/a-maravilhosa-teta-chamada-soa/

emerleite:

Exatamente. Saca só o drama da empresa onde trabalho atualmente …
http://emerleite.wordpress.com/2008/02/15/a-maravilhosa-teta-chamada-soa/

Rapaz, eu conheço empresas que trabalham a anos com EAI e serviços de mensageria em geral aonde os arquitetos nem sonhavam da existência do “Enterprise Integration Patterns”, não conheciam ferramentas ESB e ainda enchiam a boca pra dizer que JMS “não serve pra isso”.

Eu tenho é medo quando eu vejo gente falando por aí hoje em ESBs, “arquiteturas orientadas a serviços”, BPM e afins, é merda na certa. E das fedorentas.

Realmente é triste. Pouco provavel conseguir implantar integrações e SOA com qualidade sem ter lido a literatura do Gregor Hohpe.

rubinelli:

rodrigoallemand:

Vc acha mesmo que as consultorias [A-Za-z]{3} vão morrer mesmo por causa da sua metodologia?!?!? Tem certeza?!?!? Mas do fundo do seu coração mesmo?!?!?
E o CMMI for Acquisition, que é um dos modelos de CMMi?!? Vc acha que as empresas vão comprar hardwares por metodologias ageis tambem?!?!? Jura?!?
E pior sobre as [A-Za-z]{3}, os clientes delas vão falir por causa das consultorias que utilizam metodologias que não são ageis?!?!?

P.S.: É, cv, o seu [A-Za-z]{3} pegou mesmo!

Tem gente que está falando com o coração e não com a cabeça. Depois que você vê falarem em “agile waterfall” a sério, como eu vi, você começa a perder a fé na humanidade…

CMMi, PMI, ITIL, WS-Deathstar, ESB, e a construção de pirâmides tecnológicas que não têm outro propósito senão exaltar o poder dos projects sponsors nos acompanharão por muito tempo ainda.

rodrigoallemand, a resposta do rubinelli responde suas perguntas sobre o que escrevi

Não acho que irão afundar, mas eu quero mais é que afunde. E pode levar junto alguns estúpidos deptos de TI de clientes também

T+

Maurício Linhares:

emerleite:

Exatamente. Saca só o drama da empresa onde trabalho atualmente …
http://emerleite.wordpress.com/2008/02/15/a-maravilhosa-teta-chamada-soa/

Rapaz, eu conheço empresas que trabalham a anos com EAI e serviços de mensageria em geral aonde os arquitetos nem sonhavam da existência do “Enterprise Integration Patterns”, não conheciam ferramentas ESB e ainda enchiam a boca pra dizer que JMS “não serve pra isso”.

Eu tenho é medo quando eu vejo gente falando por aí hoje em ESBs, “arquiteturas orientadas a serviços”, BPM e afins, é merda na certa. E das fedorentas.

Mauricio, concordo contigo que existem muitas formas de se integrar, mas arquiteturas SOA não são exatamente um Lixo. Talvez não da forma como a maior parte dos consultores implementa, mas para uma empresa que precisa ter “componentes intercambiáveis” em plataformas heterogêneas e coordenados ( Orquestrados como gostam de falar BPM) para formar um serviço, a linha de pensamento pode sim fazer sentido.

Talvez a implementação desses não seja a mais adequada, aí é olhar soluções existentes no mercado e conceber uma solução que realmente faça sentido à sua estratégia, como citado, mensagens assíncronas.

O que realmente acontece e vejo todos os dias isso na empresa, é que muitos consultores rezam a cartilha da companhia sem estudar à fundo a base.

Mas vi muita gente também criticando WS-SOAP sem base alguma ou justificativa em seu favor. Existem cenários que você precisará hoje usar SOAP, um deles é mercado financeiro, onde a segurança da informação é levado à sério, e tramitar somente sobre https não é necessariamente o primor para essa necessidade.

Não há SilverBullet e concordo que o REST acaba com a complexidade do WS- Entretanto, no mercado Enterprise a arquitetura acabará sendo uma dobradinha.

Há outras tecnologias para integração, concordo, como JMS e aqui entra o Papel do ESB, talvez para expor o serviço a uma organização do serviço - WorkFlow, via um BPM da vida.

Um case de Real World: http://www.cauldwell.net/patrick/blog/PermaLink,guid,9ba58b84-f978-4b49-8aa5-5c2c0e0c9458.aspx

Kenobi:

Mauricio, concordo contigo que existem muitas formas de se integrar, mas arquiteturas SOA não são exatamente um Lixo. Talvez não da forma como a maior parte dos consultores implementa, mas para uma empresa que precisa ter “componentes intercambiáveis” em plataformas heterogêneas e coordenados ( Orquestrados como gostam de falar BPM) para formar um serviço, a linha de pensamento pode sim fazer sentido.

Talvez a implementação desses não seja a mais adequada, aí é olhar soluções existentes no mercado e conceber uma solução que realmente faça sentido à sua estratégia, como citado, mensagens assíncronas.

O meu exagero é intencional

Nas próximas semanas nós vamos ter reunião do grupo de usuários Java local e o título da minha palestra é “O SOA morreu: Por uma arquitetura orientada a Recursos”

SOA hoje já está muito preso a SOAP e WS-*, perdeu o seu sentido como uma arquitetura e virou a “implementação”. Eu diria até que o home realmente foi infeliz, serviços lembram coisas que não tem estado, aonde você dá uma entrada e recebe um resultado, como uma calculadora, um recurso já tem uma apresentação diferente, ele parece uma coisa que tem estado, que está lá pra ser visto, alterado, ele representa melhor as nossas entidades dentro de um sistema e a maior parte dos web services é exatamente sobre isso, recursos e entidades, é só olhar web services famosos com o da Amazon que você percebe que o que é interessante são as entidades e não “serviços”.

É óbvio que o conceito de SOA em si vai muito além e não está preso aos web services baseados em SOAP, mas não é isso que os fornecedores de soluções SOAP falam, eles vendem as suas ferramentas como se fossem a última cocada do tacho e isso levou muitos “arquitetos” a acreditar que eles são, realmente, a melhor solução, tanto que muita gente caiu de boca na brincadeira e dançou. Já vi muita gente “criando” web service no Visual Studio usando um DataSet como fonte de dados e sabe como é que fica o WSDL, um “any element”, não tem ferramenta Java que entenda que diabos é isso. Cadê a interoperabilidade desse troço?

SOAP nasceu errado, nasceu na dependência de que todas as ferramentas implementariam o padrão do mesmo jeito e que tudo ia funcionar perfeitamente. Mas assim como não funcionou pra Corba, EJBs, JSF e outras tecnologias que dependiam de “ferramentas” pra poder trabalhar, falhou miseravelmente.

Acho que existem sim muitas formas de se implementar uma arquitetura aonde pequenas aplicações sejam especializadas em implementar determinadas partes do trabalho, assim como também existem diversas formas de se implementar a famigerada “orquestração” (eu, pessoalmente, detesto o termo), o problema é quando todos procuram os modos mais difíceis de se fazer isso sem nem parar pra considerar que o investimento em complexidade não vai se pagar nem no médio nem no longo prazo. É muito difícil de se encontrar uma empresa que realmente tenha necessidade (e, principalmente, capacidade) pra montar um ESB e fazer uso de verdade dele, não é uma simples questão de chegar alguém e dizer que “agora tudo é serviço”, é uma questão de se formar uma conciência nas pessoas de que agora eles não são mais equipes de desenvolvimento separadas, mas pequenos grupos de um grupo maior que tem que se preocupar com muito mais do que “escrever uma aplicação”. Dar manutenção em APIs públicas, especialmente num ambiente complexo como um ESB, não é um trabalho trivial e o “motorista de gerador de WSDL” com certeza não é uma pessoa com capacidade pra fazer isso.

Kenobi:

O que realmente acontece e vejo todos os dias isso na empresa, é que muitos consultores rezam a cartilha da companhia sem estudar à fundo a base.

Mas vi muita gente também criticando WS-SOAP sem base alguma ou justificativa em seu favor.

Criticar WS-SOAP é incrivelmente fácil, é só você ter passado por um projeto de integração de linguagens/tecnologias/runtimes diferentes, tipo Java + Perl ou Qualquer coisa + .Net, são histórias pra se carregar pela vida toda

Eu nem queria dizer que REST é silver bullet, mas nesse caso, infelizmente, eu não consigo ver problema algum em se usar REST. A informação de endereçamento é parte do recurso nesse caso, então a representação do recurso teria que vir junto com a representação do endereçamento da máquina, o que ele fez foi mover uma informação que é do domínio (a localização/identificação do leitor preso ao tranformador) pra fora dele, colocando num cabeçalho SOAP, é uma escolha arquitetural que pode ter sentido no caso dele, em REST não faria sentido algum, essa informação faz parte do recurso, então tem que vir junto dele ou pelo menos ser referenciada de forma que seja possível pegar ela também.

Um caso aonde eu acho que tentar fazer com REST é perda de tempo é mensageria assíncrona, especialmente se você estiver rodando em cima de HTTP, então o melhor a se fazer é correr pra uma ferramenta especializada em fazer isso (o que? ws-reliable-messaging? não, obrigado ).