Idea of pushing some data(state or worst object itself) across wire with interop across languages has been one concept which has seen umpteen births. I hope we do not have to invent, adopt any new RPC for sometime.
Because I am done.
DCOM to Remoting
– MTS was the last decent app server which did not evolve into app servers as on other side(offcourse the ejb and friends) where firms made whole lot of money by providing layers to intercept, modify, throttle the object/message passing. ChannelFactory/sinks and friends were at best whole lot of method call to message magic. So many sinks were written before good souls realized that it is sin to write so many sinks….
Then we had realization that we can live together and had madness around interop. Does not happen. Try looking at WS-Security and friends, it is still nightmare to think about it.
.Net had two separate paths in scheme of things. Slowly they got integrated with IIS and its ‘isms. (provisioning, invocation, pipeline )
1. WCF (SOAP , WS * Services – TX, security using envelopes/headers)
– classic
– ria services (silverlight )
– data services (astoria) , OData precursor
– web HTTP
2. IIS hosted world evolved and adopted much faster indicating where the world is going and proving Web server is the app server.
ASP.NET (http verbs and resource representation overtime )
– asmx
– mvc (yes folks used this to provide an api endpoint)
– web api (no tcp, no mq, no soap, hopefully savior for some time)
– web api data
Lately (over 5 years ) we have seen resurgence of which serialization is better, which rpc method can work across languages. Fortunately this time folks are more pragmatic.
New serialization cum rpc friendly layers
– Bond *yeah microsoft’s – https://github.com/Microsoft/bond
– Avro (schema as json inside header)
– Thrift (Facebook – just rpc)
– Protocol Buffer(google origin – c++ layer over rpc)
– MessagePack (json in binary encoding)
Other side has had Corba to remoting, web services- JAX-RS, JAX-WS and myriad rest frameworks. You just live with poison of choice like Shiva..just be ready to replace it.
Nothing is right or wrong but the amount of technical debt you build up is amazing. Having worked with customers, applications over time I some times I mull over best solution which can evolve. Experience has taught me unfortunately some of the choices stick around for longer and evolution is challenging to say the least.
I also hope IDEs do not obscure the working behind a single click. It is the biggest disservice in name of productivity as a generation of developers put something together but have no idea of how these things work. Idea of doing F5 based projects to “quickly show” something without explaining what is happening underneath has created a heavy burden of debt. Sad part is removing these “what is happening” issues is not great use of time and energy. It should be simple, clear and not obfuscated to protect people from complexity. Definitely not where you have gladly sent 1000s of objects with arrays of data…
https://servicestack.net/text, http://www.newtonsoft.com/json are the best choices for really efficient json encoding if you can’t suddenly move to MessagePack or others.
It is worth paying to servicestack for the efficiency they bring compared to default .net xml/json serializers.
On personal level A pragmatic Web API with right amount of marriage with “actions on resources” is what I push for when customers request design reviews. It may not pass all the “rest” tests – but it is much easier to evolve.
Some place else 