Re: The Revenge of the Geeks

From: Arved Sandstrom <asandstrom2_at_eastlink.ca>
Date: Sat, 26 Jan 2013 07:25:49 -0400
Message-ID: <23PMs.86405$sm1.44698_at_newsfe22.iad>



On 01/26/2013 01:31 AM, BGB wrote:
> 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?

[ SNIP ] Both CORBA and DCOM are meant for distributed applications. Like Arne said, both have to do with software components on numerous different machines, possibly different languages, and having defined interfaces for RPC. Myself I wouldn't even use the term "server" to explain what DCOM and CORBA do, not at a high level.

>>> 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).
>>>
[ SNIP ]

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

[ SNIP ] Don't make the mistake of thinking that Java EE == web application. Although I expect that a lot of Java coders who write only web apps in the Java EE space may get to thinking that way.

Your typical Java EE enterprise app running on top of a Java EE application server may or may not have a web tier. Just like servers written in other languages on other platforms may often also have nothing whatsoever to do with HTTP and HTML and web browsers.

But I suppose if you look at the numbers of Java EE app deployments, I'll speculate that the very large majority are web apps or at least incorporate one.

Since you mentioned PHP, and Arne mentioned JSP, you're aware that you might run a PHP app on Apache with mod_php. Think of that latter as being your app server. Similarly, if you want to run an ASP.NET MVC app, you might set up an IIS website for it - IIS is your app server. In the case of Java EE web apps using JSP as a view technology (with or without JSF in the picture) then a Java EE server is your application/web server.

AHS Received on Sat Jan 26 2013 - 12:25:49 CET

Original text of this message