On 01/20/2011 10:50 AM, Heiko Braun wrote:
On Jan 20, 2011, at 5:29 PM, Jason Greene wrote:
>>
>> I also don't understand the true benefit of running the console
>> somewhere other than the DC. Why have the extra network hop for every
>> DC request? Just call the API directly instead of messing with the
>> extra complexity of remoting.
>
> Agreed. Ideally the console would be served up from the DC, as it's the most
natural fit; however the DC and HC process need to have minimal overhead.
All I am trying to say it that you loose flexibility when you tie them together.
Whatever deployment consideration taken for the console will then directly affect the DC
or REST interface.
I.e. moving the console to the DMZ (demilitarized zone), would require exposing the DC or
REST interface there as well.
Do you know what I mean? Hence the idea to keep it decoupled and rely on the java
protocol underneath.
Why is everyone so afraid of extra network hops and serialization overhead?
I think we are going to have a kickass remoting protocol, no?
Of course we are. :) Let me lay it out this way though:
DC Dependencies with Web Console and REST API
---------------------------------------------
- Remoting and dependencies
- Modules, MSC, DMR, a few other core things
DC Dependencies without Web Console and REST API
------------------------------------------------
- Remoting and dependencies
- Modules, MSC, DMR, a few other core things
See? It costs nothing to put the web console and REST server in the DC
that we aren't already paying elsewhere. I think putting these together
is the most logical choice, and I think putting them both in the DC is
the best solution. Especially when you consider that separating them
from the DC adds costs without removing any.
--
- DML