Re: The Revenge of the Geeks
Date: Fri, 25 Jan 2013 22:05:42 -0500
Message-ID: <5103480d$0$284$14726298_at_news.sunsite.dk>
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.
> 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.
> 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.
>>>>> 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.
Arne Received on Sat Jan 26 2013 - 04:05:42 CET