Re: The Revenge of the Geeks
Date: Sat, 26 Jan 2013 09:12:12 -0500
Message-ID: <5103e445$0$288$14726298_at_news.sunsite.dk>
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 Received on Sat Jan 26 2013 - 15:12:12 CET