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