Re: The Revenge of the Geeks
Date: Sat, 26 Jan 2013 14:47:33 -0600
Message-ID: <ke1ffk$vmg$1_at_news.albasani.net>
On 1/26/2013 8:12 AM, Arne Vajhøj wrote:
> On 1/26/2013 12:31 AM, BGB wrote:
>> On 1/25/2013 9:05 PM, Arne Vajhøj wrote:
>>> On 1/24/2013 11:31 PM, BGB wrote:
>>>> I actually have little idea how DCOM or CORBA fits into this, as they
>>>> are network protocols (like for doing RPC),
>>>
>>> They are not.
>>>
>>> CORBA is a component model that uses IIOP as network protocol.
>>>
>>> DCOM is a component model that uses ncacn_tcp as network protocol.
>>>
>>
>> fair enough...
>>
>> I haven't really used either of them personally, FWIW.
>>
>> I will assume then that they are probably for inter-operation with other
>> servers or similar?
>>
>> (though I guess client/server communication was mentioned earlier, like
>> the end-user clients could call back to the server).
>
> They are really fir inter-operation between components,
>
> But it will typical be some application on a server that host those
> components.
>
ok.
>> FWIW: I once messed briefly with XML-RPC, but never really did much with
>> it since then, although long ago, parts of its design were scavenged and
>> repurposed for other things (compiler ASTs).
>
> XML-RPC never really took off. Instead we got SOAP.
>
I don't really like SOAP...
IMHO, it seems wasteful and probably like a dedicated protocol could probably be more efficient in most cases.
not that high-level code should see (or need to care about) the raw bytes going over the socket, but avoiding being overly wasteful does seem like an advantage.
the usual strategy I had used is that high-level messages are seen basically as structured data (list-structured data, or "tuples"), with the protocol code basically being responsible for bundling them up, serializing them (into a binary form), and sending them on their way.
admittedly, some of my views regarding high-level network programming may have also been influenced some by (limited) exposure to Erlang. (though, granted, a lot of my stuff works differently from Erlang...).
>>>> but, for most client/server apps I am familiar with are more like:
>>>> server runs somewhere (opening a listen port, for example, port 80 for
>>>> HTTP, ...);
>>>> user downloads and runs client;
>>>> client opens socket to connect to server (such as TCP or UDP);
>>>> then they share whatever data is relevant over the socket, using the
>>>> relevant protocol (often application-specific).
>>>>
>>>> say, the protocol does structured message delivery, either using globs
>>>> of XML (like Jabber/XMPP or similar), or maybe some specialized binary
>>>> message format, and sometimes with a "multiplexer" to avoid clogging up
>>>> TCP sockets with large messages (by breaking large messages into
>>>> smaller
>>>> pieces), ...
>>>>
>>>> then each end sees the messages, and handles them as appropriate (or
>>>> reassembles the pieces, and handles complete messages when they
>>>> arrive),
>>>> ...
>>>
>>> Let me give you a very simple example.
>>>
>>> You want to allow browsers to connect to your code and be
>>> told what the time is.
>>>
>>> You could write that in Java SE. You listen on port 80, accept
>>> a connection, start a thread that parse the request and outout
>>> the response.
>>>
>>> With Java EE you could write now.jsp:
>>>
>>> <%=new Date()%>
>>>
>>> and Java EE would handle sockets, threads, reading and writing for
>>> you.
>>>
>>> The JSP get compiled to Java that get compiled to byte code that
>>> get JIT compiled.
>>>
>>
>> ok, so it does something sort of like a web-server then, but with Java
>> taking the role of PHP or similar?
>>
>> I guess maybe that has to do with the whole "application server" thing,
>> which was another part I didn't really understand what it was doing
>> exactly...
>
> A full Java EE server comes with a web container and an EJB container.
>
> Tomcat etc. only comes with web container.
>
> The web container part of Java EE is for writing web applications
> and web services in Java EE similar to PHP and ASP.NET.
>
> The EJB container part does not speak HTTP(S). Instead
> it uses binary calls over sockets, message queues and
> allows for custom TCP and UDP traffic (via JCA).
>
yes, ok.
in my case, though not exactly the same, it is possible to have custom messages composed by, and processed by, script code.
I don't generally use RPC, nor send code over the network protocol, mostly as it seemed like too much of a security risk at present (though technically, both could be done without much effort).
some of my older stuff did directly send executable code over sockets, but I now generally consider this to be bad practice, and some other things which could potentially send code include automatic filters to try to prevent any script fragments from being sent (many of these sorts of messages will be discarded).
this may change if/when general security improves (mostly so that script code can be adequately sand-boxed).
note: it doesn't block all code from being sent, rather specific black-listed cases, like sending globs of code over the network via console commands, ... mostly as these cases more likely represent nefarious uses than actually valid use-cases (valid code probably isn't going to be sent via a big "stufftext" message).
>>>> I am confused as well...
>>>>
>>>> the whole Java SE vs Java EE thing has taken a turn into the
>>>> confusing...
>>>>
>>>> the former makes sense, because that is what a person gets when they go
>>>> download and install the JDK or the JRE.
>>>>
>>>> but the latter?... dunno. it sounds like something a bit different (not
>>>> just an alternate version of the JDK or JRE).
>>>
>>> Correct.
>>>
>>> Let us say that the Java SE model is:
>>> - you write some classes and build them with JDK
>>> - you start the JVM with a main method in one of your classes
>>> - your main code calls some code
>>>
>>> The Java EE model is:
>>> - you start the JVM with the Java EE app server
>>> - you write some classes and build them with JDK
>>> - you deploy your classes (no main method) to the server
>>> - the server calls your code
>>>
>>> In Java SE terms you can consider the Java EE server to be the
>>> program and your Java EE application to be a plugin to the
>>> server.
>>>
>>
>> ok.
>>
>> this much makes sense at least.
>
> The concept is sometimes call the Hollywood
> Principle.
>
not really familiar with this.
looking it up.
actually, in a general sense, this sounds like how a lot of how my stuff works internally.
direct top-down structuring usually gets overly complicated and really doesn't scale well in general. Received on Sat Jan 26 2013 - 21:47:33 CET