Re: The Revenge of the Geeks
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