Re: The Revenge of the Geeks

From: BGB <>
Date: Fri, 25 Jan 2013 23:31:16 -0600
Message-ID: <kdvppm$80q$>

On 1/25/2013 9:05 PM, Arne Vajh°j wrote:
> On 1/24/2013 11:31 PM, BGB wrote:

>> On 1/24/2013 9:15 PM, Arne Vajh°j wrote:
>>> On 1/24/2013 10:10 PM, BGB wrote:
>>>> On 1/24/2013 4:58 PM, Arne Vajh°j wrote:
>>>>> On 1/24/2013 5:10 PM, BGB wrote:
>>>>>> On 1/24/2013 10:06 AM, Arne Vajh°j wrote:
>>>>>>> On 1/23/2013 11:47 PM, BGB wrote:
>>>>>>>> but, in any case, with the other languages there are a wide
>>>>>>>> range of
>>>>>>>> libraries available, many under fairly open licenses (like MIT or
>>>>>>>> BSD),
>>>>>>>> and there is a lot more GPL stuff available,
>>>>>>> In the EE space you would need to look at CORBA or DCOM.
>>>>>>> You would prefer Java EE believe me.
>>>>>>> :-)
>>>>>> errm, so you can't just copy all the files over to ones' servers?
>>>>>> and/or
>>>>>> recompile the code for ones' servers?...
>>>>> The coding model in Java EE is definitely more modern than that
>>>>> of CORBA and DCOM.
>>>> I didn't mean like CORBA or DCOM, but probably directly copying over
>>>> program binaries (DLLs or SOs and precompiled binaries and similar),
>>>> and
>>>> probably using traditional compilation and linking.
>>> You lost me.
>>> How to get the same type of services as Java EE provides is related
>>> to copying binaries how?

>> I may be missing something here...

>> because... it involves linking against and using libraries, correct?...

>> like "both languages have libraries, but maybe not the same libraries".

>> as in, for Java, you can copy around and use a JAR.
>> or in C or C++, you link against the DLL or SO, or use a static-library
>> (which then becomes a permanent part of the binary), ...

>> like, for Java there is LWOGL, and for C there is "opengl32.dll".
>> or, one person uses AWT or Swing, and another uses GDI+ or WinForms.

>> if you have some program and need to run it on a web-server, it can be
>> copied over into its "cgi-bin/" directory or similar, or set it to run
>> at start-up as a deamon (or a as a service on Windows, or launch it via
>> "start-up applications" or similar).

>> if end users run a program, they typically download it off the internet,
>> maybe as a ZIP, or maybe as a self-extracting "setup.exe" or similar.

>> any libraries would be contained inside, and copied over into the
>> relevant directories. any data files are typically copied along as well,
>> and the installer might put everything in its place.

>> and, if a person needs new libraries for a project they are developing,
>> they will go and download them off the internet, maybe recompile it from
>> source, ...
> You copy jar files in Java EE just like you do in Java SE.
> The difference is in what the libraries do. Not how they are
> distributed.

yes, ok.

>> 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).

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).

my own network protocol designs had typically revolved around (typically asynchronous and unidirectional) message passing (basically, both ends throwing messages at each other over a socket).

usually, these weren't based on HTTP or similar, but typically special dedicated sockets.

for example, my game protocol currently uses TCP/18512, and is based on compressed S-Expressions.

(sound 594 "sound/monsters/enemyhead/idle1" ...) would match against the tag 'sound', and then invoke the appropriate handling logic (which looks up entity 594, tells the mixer to start playing the sound-effect in question, which is connected to the entity, ...).

>> 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...

>>>>>> as for data sharing (between lots of networked servers), I am less
>>>>>> sure,
>>>>>> I would think maybe something like NFS or SAMBA, but then thinking of
>>>>>> it, NFS or Samba might not scale well if the number of servers
>>>>>> becomes
>>>>>> sufficiently large (like, people would probably want to locally cache
>>>>>> files, rather than always doing IO over the network, ...).
>>>>> Persistent data in the the Java EE world is most often in database.
>>>> well, I meant for code and other resources.
>>>> or, to you mean putting code in the database as well?...
>>>> (like, put the JAR in a data-blob and fetch it out via a SELECT or
>>>> something?...).
>>> No.
>>> But as I said I am lost.

>> 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.


this much makes sense at least. Received on Sat Jan 26 2013 - 06:31:16 CET

Original text of this message